headers
John W. Linville | 1 Feb 02:17
Favicon

wireless list moved to vger.kernel.org

In response to some community requests, I have asked David
Miller to create a list for us on vger.kernel.org.  David has
obliged that request, so I have restricted new subscriptions to
wireless at lists.tuxdriver.org and I am asking everyone to move wireless
discussions to the new list.

	linux-wireless at vger.kernel.org

Most of you should have been automatically subscribed to the new list.
I think there are a handful of people who joined the tuxdriver list
within the past 6 hours or so.	Those people may need to subscribe
themselves to the vger list.

Sorry for the confusion.  FWIW, vger is probably a better home for
our list anyway.

Thanks,

John
--

-- 
John W. Linville
linville at tuxdriver.com
Permalink | Reply | 0 comments |
headers
Johannes Berg | 1 Feb 14:07
Favicon

[RFC] cfg80211 merge

On Thu, 2007-02-01 at 01:54 +0200, Tomas Winkler wrote:
> As far as I tested cfg80211 compatibility mode is incomplete. You
> cannot run hostapd over it
> If I recall correctly PRISM2_IOCTL_PRISM2_PARAM and friends are not
> passed to d80211 

It's a priv ioctl, it's not supposed to be passed on.

johannes (who is getting positively pissed off about such requests)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part
Url :
http://lists.tuxdriver.org/pipermail/wireless/attachments/20070201/efd11861/attachment.pgp
Permalink | Reply | 4 comments |
headers
Johannes Berg | 1 Feb 11:18
Favicon

[RFC PATCH 1/3] cfg80211 and nl80211

On Tue, 2007-01-30 at 21:46 -0500, Michael Wu wrote:

> I think drivers that currently support frame injection do it by allowing TX on 
> a monitor interface w/ AVS or radiotap header. I would rather have this than 
> requiring the use of NL80211 to inject frames since userspace won't have to 
> do as much to continue supporting frame injection. It also makes more sense 
> to me. Status notification can be done by a 802.11 ACK frame. Radiotap might 
> need to be extended to support toggling the ACK frame reporting for TX and 
> whatever else userspace wants to set.

I disagree. Generic netlink is trivially extensible while radiotap
isn't, and I really don't want a radiotap parser in the kernel.
Secondly, a lot of notification items will only be given via netlink
anyway, like failed decryption or whatever, and we don't want to keep
all this in fake management frames.

> > +	/* configuration sent from kernel */
> > +	NL80211_CMD_NEW_CONFIG,
> > +
> Why NEW?

I think Thomas suggested the scheme GET/SET/NEW but I don't really care.

> [snip]
> > +	/* currently set roaming BSSID */
> > +	NL80211_CMD_FIXED_BSSID,
> > +
> Wasn't immediately obvious to me that this is from GET_FIXED_BSSID.

should get a NEW prefix as well then? :)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tomas Winkler | 1 Feb 15:04
Picon

[RFC] cfg80211 merge

Can you elaborate shortly.  I'm not from time 0 on this list.
Thanks.

On 2/1/07, Johannes Berg <johannes at sipsolutions.net> wrote:
>
> On Thu, 2007-02-01 at 01:54 +0200, Tomas Winkler wrote:
> > As far as I tested cfg80211 compatibility mode is incomplete. You
> > cannot run hostapd over it
> > If I recall correctly PRISM2_IOCTL_PRISM2_PARAM and friends are not
> > passed to d80211
>
> It's a priv ioctl, it's not supposed to be passed on.
>
> johannes (who is getting positively pissed off about such requests)
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.tuxdriver.org/pipermail/wireless/attachments/20070201/397cf333/attachment.htm
Permalink | Reply | 3 comments |
headers
Johannes Berg | 1 Feb 15:11
Favicon

[RFC] cfg80211 merge

On Thu, 2007-02-01 at 16:04 +0200, Tomas Winkler wrote:
> Can you elaborate shortly.  I'm not from time 0 on this list.

Well. cfg80211 will replace the common wext ioctls. All the private wext
ioctls will not be handled there.

The rationale is that
 (1) it doesn't delete priv ioctls, they'll still work for the migration
     period
 (2) you can't rely on private ioctls having a certain meaning for each
     driver, ie. other drivers are free the reassign numbers of
     sub-ioctls
 (3) any behaviour that is generally useful should be standardised.

johannes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part
Url :
http://lists.tuxdriver.org/pipermail/wireless/attachments/20070201/7a106843/attachment.pgp
Permalink | Reply | 1 comment |
headers
Jiri Benc | 1 Feb 15:12
Picon

[RFC] cfg80211 merge

On Thu, 1 Feb 2007 16:04:53 +0200, Tomas Winkler wrote:
> Can you elaborate shortly.  I'm not from time 0 on this list.
> Thanks.

Use Google and list archives, that's why their exist.

 Jiri

--

-- 
Jiri Benc
SUSE Labs
Permalink | Reply | 0 comments |
headers
Tomas Winkler | 2 Feb 19:18
Picon

[RFC] cfg80211 merge

Johannes
I don't know who is missing something here, but what I'm saying that (1) is
not correct. priv ioctls don't work with compatibility  set on.
In any case I'll check it again to be sure and I will apologize if I'm not
correct.
I definitely agree on two other  points.

Thanks
Tomas

On 2/1/07, Johannes Berg <johannes at sipsolutions.net> wrote:
>
> On Thu, 2007-02-01 at 16:04 +0200, Tomas Winkler wrote:
> > Can you elaborate shortly.  I'm not from time 0 on this list.
>
> Well. cfg80211 will replace the common wext ioctls. All the private wext
> ioctls will not be handled there.
>
> The rationale is that
> (1) it doesn't delete priv ioctls, they'll still work for the migration
>      period
> (2) you can't rely on private ioctls having a certain meaning for each
>      driver, ie. other drivers are free the reassign numbers of
>      sub-ioctls
> (3) any behaviour that is generally useful should be standardised.
>
> johannes
>
>
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jon Smirl | 4 Feb 18:22
Picon

SoftMAC vs FullMAC

Has it been considered to simply treat all wireless hardware as
SoftMAC and to just ignore the FullMAC capabilities?

Doing this would effectively turn all wireless hardware on Linux into
commodities stopping this chaos of all the different implementations.
Network speeds on wireless are not very high, things may even be
faster if done on the main CPU.

Wired networking went through this exact process in the 80's. There
were cards with complete TCP systems running on embedded processors.
Ultimately this shook out to the dumb hardware we have today. This
happened for two reasons, the main CPU was cheaper/faster and there
were fewer interoperability problems when only a couple of stacks were
being used instead of dozens.

Dscape looks to have already started down this path with
implementations for five vendors. Is the plan to do this for all
vendors, including Intel and Atheros?

My specific need is that I am working on an embedded design that
really needs 802.11s, but 11s isn't available yet. I don't want to end
up locked into a hardware vendor's FullMAC implementation with much
more expensive hardware. Currently hardware can run 11s if there is a
host implementation in software.

Meanwhile I am trying to hack something together using OLSR. Is there
a better way to get mesh working?

--

-- 
Jon Smirl
(Continue reading)

Permalink | Reply | 14 comments |
headers
Pavel Roskin | 4 Feb 18:30
Picon

Re: SoftMAC vs FullMAC

Quoting Jon Smirl <jonsmirl@...>:

> Has it been considered to simply treat all wireless hardware as
> SoftMAC and to just ignore the FullMAC capabilities?
[skip]
> Dscape looks to have already started down this path with
> implementations for five vendors. Is the plan to do this for all
> vendors, including Intel and Atheros?

It is the plan for Atheros.  See Dadwifi.

In fact, Atheros chips are not that intelligent to be treated as FullMAC, but
going to d80211 removes many chip specific features.

--
Regards,
Pavel Roskin
-
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 10 comments |
headers
Jouni Malinen | 4 Feb 19:07
Picon
Picon

Re: SoftMAC vs FullMAC

On Sun, Feb 04, 2007 at 12:22:15PM -0500, Jon Smirl wrote:
> Has it been considered to simply treat all wireless hardware as
> SoftMAC and to just ignore the FullMAC capabilities?

There are number of FullMAC designs that do not allow management
functionality to be moved to the host, so this consideration is not
going to go very far unless one were to drop support for all the FullMAC
designs that do not allow this..

> Dscape looks to have already started down this path with
> implementations for five vendors. Is the plan to do this for all
> vendors, including Intel and Atheros?

Atheros (well, assuming you don't mean the USB design here) does not
even use firmware, so it is not FullMAC card in any way.. There is
already work on supporting Intel ipw3945 with d80211. Other Intel
designs (ipw2100, ipw2200, ipw2915) are currently using more FullMAC
type design, but that depends on the firmware implementation.. I don't
know what the hardware would be capable of doing, but in theory, it
might be possible (for the vendor) to produce a firmware version that
could work soft MAC designs.

> My specific need is that I am working on an embedded design that
> really needs 802.11s, but 11s isn't available yet. I don't want to end
> up locked into a hardware vendor's FullMAC implementation with much
> more expensive hardware. Currently hardware can run 11s if there is a
> host implementation in software.

I hope you realize that 802.11s is in very early steps (the first draft
failed to get the needed approval rate in IEEE 802.11 working group) and
(Continue reading)

Permalink | Reply | 2 comments |

Gmane