Re: Where Linux 802.11x support needs work

Re: Where Linux 802.11x support needs work

[Jean Tourrilhes]

Dan Williams wrote :
> 
> This list of stuff that should get fixed in Linux wireless grew out of my 
> attempt to put a GUI on top of Linux wireless with NetworkManager 
> (http://people.redhat.com/dcbw/NetworkManager).  This isn't, of course, a 
> demand or anything, and I've been personally slowly fixing stuff up as I 
> come to it (orinoco merge, fixing linux-wlan-ng, small kernel wireless 
> driver patches)

	Yes, I've seen your various contributions for the various
drivers. I'm glad that someone is doing all these little fixes,
because they are needed, and such a job is not gratifying and not well
recognised. I used to do more of that, in the past, when I had more
time, and Pavel did some, but it's not our full time job to work on
Linux.
	I also want to thank you for your work on the NetworkManager,
it's a great piece of work and goes beyond what I had in mind when I
created the API.

> I think the biggest issue here is that the Wireless Extensions API has 
> stagnated a bit, and driver writers have gone off and done their own thing 
> (for example, WPA support) because the WEAPI hasn't shown leadership in 
> this area.  That's fixable, and at this point doesn't seem to be a large 
> amount of work since the main offender here is only WPA.

	You know already that in Linux things happen by pushing
patches around, not by "showing leadership" (whatever that
means). Driver authors will always do their own thing, nobody can
prevent them, and it's actually a good thing as it creates inovation
and the best ideas can then be folded back into the official API. Yes,
I believe in the bottom up approach (cheers).
	Note that API doesn't happen in isolation, you need to make
things happen on both sides of it, and the API feed on the experience
of both sides.
	Because NetworkManager is both useful and standard, it will
show leadership and force driver authors to conform to its
requirements. If a driver is broken with NetworkManager, users will
bug the author until it's fixed. I've seen that happening with various
other tools (unfortunately, my wtools are too permissive).

> o  Quality values vary wildly or are absent
>      - Average and max quality levels for almost all drivers are
>         artificial and don't come from the the card in any way

	Those can't come from the hardware, they may only come from
the spec, when available.
	The idea with "average" and "max" would be that application
authors would feed back driver authors as to what to
use. Unfortunately, it did not happen, especially that apps decided to
ignore them.

> o  Frequency values vary wildly from iw_get_range
>   1) prism54 uses completely different exponent values than airo
>   2) airo, atmel, orinoco are the same

	Nobody in their right mind would use iwfreq for anything, it's
just used to go across the kernel interface. Once in userspace, just
use the iw_freq2float() and iw_float2freq() to convert to double, and
then it's all normalised.
	If you need it, I can donate you those two functions under LGPL.

> o  Not all drivers have correct netlink support, if they even have it

	Note that netlink make only sense in Managed mode, it does not
make sense in Ad-Hoc or Master mode. That make things a bit more messy
to implement.
	In the interim, for driver that don't support netlink you can
check the value of the AP address.

> o  Not all drivers support wirless scanning
>   1) orinoco driver mainly, support is upstream and is being slowly
>      merged into the kernel driver

	Just for your info, I was the one who originally authored the
Scanning patch for the Orinoco driver (based on other patches). After
that many people improved on it.

> o  Ad-Hoc mode support is quite flaky or absent from most drivers

	Low priority for most vendors, firwmares are only lightly tested.

> o  WPA support is lacking or just in-progress, needs much help

	Preliminary patch is on my web page :
http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Tools.html#wext
	Jouni is the main author, as he is doing the supplicant. He
told me that he want to make a few additional changes. WPA is quite
complex and therefore I would prefer to make sure it's right.


	Note that various other people have their own todo list. Jeff
also has things he has in minds. I have (few) patches on my web
pages. Driver authors also have their wishes.
	One of the big item not mentionned by you is the in-kernel
802.11 stack (native frames and management). If done right, I guess it
would mostly be transparent to you...

	Have fun...

	Jean

Re: Where Linux 802.11x support needs work

[Dan Williams]

On Tue, 25 Jan 2005, Jean Tourrilhes wrote:
> 	You know already that in Linux things happen by pushing
> patches around, not by "showing leadership" (whatever that
> means). Driver authors will always do their own thing, nobody can
> prevent them, and it's actually a good thing as it creates inovation
> and the best ideas can then be folded back into the official API. Yes,
> I believe in the bottom up approach (cheers).

Quite true, and I don't think that's a bad approach, I just think that 
adding general WPA support to WEAPI a bit earlier might have saved some 
trouble.  Since most driver writers have their drivers in the kernel, and 
since the kernel can enforce usage of the WEAPI on the driver, it seems 
like the WEAPI would be a good place to standardize new stuff like WPA 
that's been around for a while and is supported by a fair # of chipsets.  
Furthermore, if an API were in place, then driver writers could write to 
that API and not have to invent one themselves.  Of course, the API would 
need to change and evolve as driver writers ran into limitations and 
whatnot.  So I guess its a toss-up, either way (waiting till later, or 
starting sooner) both driver writers and user-applications have to change 
code around.  But I completely agree that flexibility is of great 
importance here.

> > o  Quality values vary wildly or are absent
> >      - Average and max quality levels for almost all drivers are
> >         artificial and don't come from the the card in any way
> 
> 	Those can't come from the hardware, they may only come from
> the spec, when available.
> 	The idea with "average" and "max" would be that application
> authors would feed back driver authors as to what to
> use. Unfortunately, it did not happen, especially that apps decided to
> ignore them.

My frustration here (and why I've pretty much stopped trying to fix it) is 
basically twofold:
1) If the card only reports dBm, I cannot try to calculate the 
signal-to-noise ratio without getting the correct noise level.  Only the 
card can provide that, and quite a few do not.
2) The API here is a bit confusing and lacks some documentation.  Since we 
have the 8-bit value for the quality, the driver has the choice of either 
0 - 255 (which seems to be what Airo uses) or -128 - +128 (which others 
use).  I could not really deduce what the values that various drivers 
return is, and how to convert that to a percentage value.

For quality data, we have qual.qual, qual.level, and qual.noise.  Its not 
completely clear what each of those values is (though if I had to guess, 
I'd assume qual.qual = %-age value, qual.level = dBm of current signal, 
qual.noise = dBm of current noise threshold).

The breakdown:
ipw2200: fairly sane
ipw2100: fairly sane, but no scan quality data
airo: only qual.level on scans (qual.qual/qual.noise = 0), for normal
      quality uses a lot of magic numbers.  No way to get a percentage
      value out of this driver.
atmel: magic numbers tied to one hardware version.  No scan quality data.
orinoco: magic numbers
madwifi: doesn't seem to implement SIOCGIWSTATS

As far as I understand the comments in iwlib.c, all drivers do something 
different for the qual.qual/qual.level/qual.noise fields, WRT the 
signed/unsigned debate.  Airo seems to use 0 - 255, others seem to use 
-128 - +128, etc.  We need to standardize signal strength and quality data 
among the drivers.

> > o  Frequency values vary wildly from iw_get_range
> >   1) prism54 uses completely different exponent values than airo
> >   2) airo, atmel, orinoco are the same
> 
> 	Nobody in their right mind would use iwfreq for anything, it's
> just used to go across the kernel interface. Once in userspace, just
> use the iw_freq2float() and iw_float2freq() to convert to double, and
> then it's all normalised.
> 	If you need it, I can donate you those two functions under LGPL.

AFAIK, those functions are exposed in iwlib, no?  I think I'm already 
using them in NetworkManager.  I was using get/set frequency calls (which 
only madwifi actually seems to support) to ensure that the card jumps to 
the correct frequency in Ad-Hoc mode, which it didn't always seem to do.

> > o  Not all drivers have correct netlink support, if they even have it
> 
> 	Note that netlink make only sense in Managed mode, it does not
> make sense in Ad-Hoc or Master mode. That make things a bit more messy
> to implement.
> 	In the interim, for driver that don't support netlink you can
> check the value of the AP address.

True, but some tools like wpa_supplicant seem to use the netlink sockets 
stuff to trigger auth/encryption capability checks since certain auth 
algorithms send challenge packets to you when you auth/assoc to the AP.  
In any case, I'm not actually using any netlink sockets support in NM 
since its just to flaky between drivers.

Checking the AP MAC address isn't really good enough, since cards have 
different semantics here.  Some cards seem to update the MAC address only 
when you've successfully authed/assoced to the AP, while others don't 
really care as long as you've pointed your card at the ESSID.  For 
example, airo driver won't set a valid ESSID on the card until the auth 
mode is correct (ie OpenSystem/SharedKey), while others (madwifi, atmel) 
will happily show a valid MAC address even if your WEP key is wrong (airo 
will still show invalid in this instance).

The only way that I've found to guarantee a link to an access point is to 
set the ESSID, and then check over a period of 10 seconds or so for a 
valid AP MAC address on the card for at least 6 seconds, and then try to 
DHCP.  If you're in Open System and DHCP fails, then you fall back to 
Shared Key and get a link, try DHCP again, etc.

What would work better is if all cards supported netlink, so that I could 
at least tell when the _card_ thought it was connected and then stop the 
whole "wait for 10s until card has link" type of deal.  Furthermore, some 
cards re-load their firmware when you set the ESSID on them, which means 
you have to wait at least 2 or 3 seconds before any value on the card is 
actually valid.  There are liberal usleep (x) sprinkled throughout places 
in NetworkManager where I have to wait for cards to bring themselves back 
up before I can do anything with them.  Even a netlink message of "I'm the 
firmware, I'm ready for business" would be an improvement for this 
problem.

> > o  Not all drivers support wirless scanning
> >   1) orinoco driver mainly, support is upstream and is being slowly
> >      merged into the kernel driver
> 
> 	Just for your info, I was the one who originally authored the
> Scanning patch for the Orinoco driver (based on other patches). After
> that many people improved on it.

Yep, I see your stamp all over the code :)  In any case, I think Dave 
Gibson was busy for a while and just never quite got around to getting the 
scanning support merged.  He seems to be doing that now though.  I tried 
to help at one point, but was using the wrong orinoco branch.  I haven't 
taken the time to extract the scanning code again however and repost that, 
because it depends on most every other change in the upstream orinoco 
drivers (better firmware capability detection, iwspy support, etc).

> > o  Ad-Hoc mode support is quite flaky or absent from most drivers
> 
> 	Low priority for most vendors, firwmares are only lightly tested.

Yeah, I don't expect much to happen here but it would be nice.  FWIW, at 
least madwifi and atmel seem to work OK here.

> > o  WPA support is lacking or just in-progress, needs much help
> 
> 	Preliminary patch is on my web page :
> http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Tools.html#wext
> 	Jouni is the main author, as he is doing the supplicant. He
> told me that he want to make a few additional changes. WPA is quite
> complex and therefore I would prefer to make sure it's right.

I plan to make NetworkManager talk to wpa_supplicant at some near-future 
point, I've had some long emails with Jouni about the wpa_supplicant 
interface and how to work with it.  I was a bit horrified to discover that 
the Open 802.1x project actually patches drivers (ok, I'm not 100% sure, 
but there are patches against kernel drivers in their CVS at least).  
However, if they have to patch kernel drivers, that probably means there's 
some capability that they need that should be in the drivers anyway, so it 
might be useful to look into those patches and see what can be 
cherry-picked to improve driver quality.

> 	Note that various other people have their own todo list. Jeff
> also has things he has in minds. I have (few) patches on my web
> pages. Driver authors also have their wishes.

True, but I'm not sure how many of those wishes/todo lists are actually 
well-known or public.  I don't really see any great momentum in the Linux 
802.11x world, but more a hodge-podge of improvements.  I was hoping that 
the post today could help  direct a bit more attention and effort at Linux 
802.11x stuff so we could try to clean it up and improve it.  I don't 
think enough people focus on this right now, and as Linux moves more 
towards mainstream we need to be as foolproof as possible.  Furthermore, 
we need to develop a clear API for driver writers so that hardware 
companies have fewer excuses to develop open-source drivers.  Obviously 
they all have tons of experience writing to NDIS/WDM, and that's fairly 
understood.  But I believe that Linux wireless driver APIs are much less 
understood and documented.

> 	One of the big item not mentionned by you is the in-kernel
> 802.11 stack (native frames and management). If done right, I guess it
> would mostly be transparent to you...

You know, I was thinking of it and I just forgot to put it on the list.  
If you're including madwifi and ipw2x00, we have a grand total of what, 3 
or 4 802.11 stacks in the kernel at the same time?  (madwifi, 
orinoco/hermes, ipw2x00, linux-wlan-ng)

Cheers,
Dan

Re: Where Linux 802.11x support needs work

[Michael Wu]

[-- Attachment #1: Type: text/plain, Size: 769 bytes --]

On Tuesday 25 January 2005 11:03 pm, Dan Williams wrote:
> >  One of the big item not mentionned by you is the in-kernel
> > 802.11 stack (native frames and management). If done right, I guess it
> > would mostly be transparent to you...
>
> You know, I was thinking of it and I just forgot to put it on the list.
> If you're including madwifi and ipw2x00, we have a grand total of what, 3
> or 4 802.11 stacks in the kernel at the same time?  (madwifi,
> orinoco/hermes, ipw2x00, linux-wlan-ng)
>
Only orinoco/hermes is in the kernel, and that doesn't really have much of an 
802.11 stack, since most things are done in hardware. Madwifi has a fairly 
complete 802.11 stack (ported from netbsd), and so does adm8211. Dunno about 
ipw2x00.

-Michael Wu

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Where Linux 802.11x support needs work

[Roar Bjørgum Rotvik]

Michael Wu wrote:
> On Tuesday 25 January 2005 11:03 pm, Dan Williams wrote:
> 
>>> One of the big item not mentionned by you is the in-kernel
>>>802.11 stack (native frames and management). If done right, I guess it
>>>would mostly be transparent to you...
>>
>>You know, I was thinking of it and I just forgot to put it on the list.
>>If you're including madwifi and ipw2x00, we have a grand total of what, 3
>>or 4 802.11 stacks in the kernel at the same time?  (madwifi,
>>orinoco/hermes, ipw2x00, linux-wlan-ng)
>>
> 
> Only orinoco/hermes is in the kernel, and that doesn't really have much of an 
> 802.11 stack, since most things are done in hardware. Madwifi has a fairly 
> complete 802.11 stack (ported from netbsd), and so does adm8211. Dunno about 
> ipw2x00.

Do any of these 80.11 stacks (or the upstream linux network stack) have 
a solution for WLAN cards with 802.11e (QoS extension) with more than 
one HW/firmware transmit queues?

As you may or may not know WLAN cards implementing 802.11e may have more 
than one HW/firmware transmit queue (I know of an 802.11a chip with 
802.11e extension that have 4 transmit queues in hardware/firmware with 
different priority).

As far as I know the linux network stack today only have one qdisc queue 
pr. device (struct netdev), so the driver may only stop/start 
(netif_stop_queue()/netif_wake_queue()) one queue at a time. This is a 
problem for drivers with more than one HW/firmware transmit queues, as 
you can not let a full low priority HW queue block the netdev queue.

Is there an existing solution for this problem, or is an 
multiqueue-pr-device solution being planned as part of introducing a 
common 802.11 stack in the kernel?

-- 
Roar B. Rotvik

Re: Where Linux 802.11x support needs work

[Michael Wu]

[-- Attachment #1: Type: text/plain, Size: 1199 bytes --]

On Wednesday 26 January 2005 2:31 am, Roar Bjørgum Rotvik wrote:
> Michael Wu wrote:
> > On Tuesday 25 January 2005 11:03 pm, Dan Williams wrote:
> >>> One of the big item not mentionned by you is the in-kernel
> >>>802.11 stack (native frames and management). If done right, I guess it
> >>>would mostly be transparent to you...
> >>
> >>You know, I was thinking of it and I just forgot to put it on the list.
> >>If you're including madwifi and ipw2x00, we have a grand total of what, 3
> >>or 4 802.11 stacks in the kernel at the same time?  (madwifi,
> >>orinoco/hermes, ipw2x00, linux-wlan-ng)
> >
> > Only orinoco/hermes is in the kernel, and that doesn't really have much
> > of an 802.11 stack, since most things are done in hardware. Madwifi has a
> > fairly complete 802.11 stack (ported from netbsd), and so does adm8211.
> > Dunno about ipw2x00.
>
> Do any of these 80.11 stacks (or the upstream linux network stack) have
> a solution for WLAN cards with 802.11e (QoS extension) with more than
> one HW/firmware transmit queues?
>
I'm not aware of any. The latest revision of the adm8211 chip supports more 
than one tx queue, but only one is used.

-Michael Wu

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Where Linux 802.11x support needs work

[Michael Renzmann]

Hi.

Roar Bjørgum Rotvik wrote:
> Is there an existing solution for this problem, or is an 
> multiqueue-pr-device solution being planned as part of introducing a 
> common 802.11 stack in the kernel?

Some (most or all?) Atheros chipsets have several priority queues. As 
far as I can tell Madwifi is prepared for supporting them, as well as 
the underlying 802.11 stack that has been ported from BSD. But I may be 
wrong, as I'm by no means a madwifi-wizard :)

Bye, Mike

Re: Where Linux 802.11x support needs work

[Michael Renzmann]

Hi.

Dan Williams wrote:
> madwifi: doesn't seem to implement SIOCGIWSTATS

It does. The SIOCGIWSTATS is used in tools/athstats.c (line 195 in 
current CVS) for example to get the rssi (via qual.qual).

>>>o  Ad-Hoc mode support is quite flaky or absent from most drivers
>>	Low priority for most vendors, firwmares are only lightly tested.
> Yeah, I don't expect much to happen here but it would be nice.  FWIW, at 
> least madwifi and atmel seem to work OK here.

Madwifi unfortunately has some known problems in Ad-hoc implementation. 
Someone worked on that, but the patches have not been sent in as far as 
I can tell.

>>	Note that various other people have their own todo list. Jeff
>>also has things he has in minds. I have (few) patches on my web
>>pages. Driver authors also have their wishes.
> True, but I'm not sure how many of those wishes/todo lists are actually 
> well-known or public.  I don't really see any great momentum in the Linux 
> 802.11x world, but more a hodge-podge of improvements.  I was hoping that 
> the post today could help  direct a bit more attention and effort at Linux 
> 802.11x stuff so we could try to clean it up and improve it.

How about setting up a project that cares of finding, defining and 
implementing such quasi-standards in the Linux 802.11 world? Most things 
are very WLAN specific, so I think netdev isn't the best place to 
discuss them. Of course this only works IMO when many (if not all) of 
the wlan driver authors join in and help out.

Comments?

Bye, Mike

Re: Where Linux 802.11x support needs work

[Dan Williams]

On Wed, 26 Jan 2005, Michael Renzmann wrote:
> 
> Dan Williams wrote:
> > madwifi: doesn't seem to implement SIOCGIWSTATS
> 
> It does. The SIOCGIWSTATS is used in tools/athstats.c (line 195 in 
> current CVS) for example to get the rssi (via qual.qual).

Except then there's no handler for it in the ath_handlers[] array:

/Users/dan/Desktop/madwifi> grep -r "SIOCGIWSTATS" *
ath/if_ath.c:   (iw_handler) NULL /* kernel code */, /* SIOCGIWSTATS */
tools/athstats.c:       if (ioctl(s, SIOCGIWSTATS, &wrq) < 0)

That makes it essentially useless for using with the Linux Wireless 
Extensions API (unless the ioctl() somehow redirets calls to SIOCGIWSTATS 
to the dev->get_wireless_stats function?).  In any case, it should be as 
simple as adding the ath_iw_getstats() function to that line in 
ath/if_ath.c in the ath_handlers[] array.  So I guess no fundamental 
problems there, should be a 20 second fix.

> >>>o  Ad-Hoc mode support is quite flaky or absent from most drivers
> >>	Low priority for most vendors, firwmares are only lightly tested.
> > Yeah, I don't expect much to happen here but it would be nice.  FWIW, at 
> > least madwifi and atmel seem to work OK here.
> 
> Madwifi unfortunately has some known problems in Ad-hoc implementation. 
> Someone worked on that, but the patches have not been sent in as far as 
> I can tell.

It actually seems to perform fairly well already.  The only problems I 
noticed were that whne you set the card into Ad-hoc mode and set the ESSID 
on the card, it dropts to a bitrate of 0 and performance is terrible.  
When you explicitly set a bitrate of 11Mbps or some other value on the 
card the it works fine.  I think the card just gets a bit confused as to 
what bitrate to use when doing Ad-hoc mode.

> >>	Note that various other people have their own todo list. Jeff
> >>also has things he has in minds. I have (few) patches on my web
> >>pages. Driver authors also have their wishes.
> > True, but I'm not sure how many of those wishes/todo lists are actually 
> > well-known or public.  I don't really see any great momentum in the Linux 
> > 802.11x world, but more a hodge-podge of improvements.  I was hoping that 
> > the post today could help  direct a bit more attention and effort at Linux 
> > 802.11x stuff so we could try to clean it up and improve it.
> 
> How about setting up a project that cares of finding, defining and 
> implementing such quasi-standards in the Linux 802.11 world? Most things 
> are very WLAN specific, so I think netdev isn't the best place to 
> discuss them. Of course this only works IMO when many (if not all) of 
> the wlan driver authors join in and help out.

This would probably be a very good thing :)

Dan

Where Linux 802.11x support needs work

[Dan Williams]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 7224 bytes --]

Hi,

This list of stuff that should get fixed in Linux wireless grew out of my 
attempt to put a GUI on top of Linux wireless with NetworkManager 
(http://people.redhat.com/dcbw/NetworkManager).  This isn't, of course, a 
demand or anything, and I've been personally slowly fixing stuff up as I 
come to it (orinoco merge, fixing linux-wlan-ng, small kernel wireless 
driver patches), but I don't think anyone has posted a comprehensive list 
of where Linux wireless currently falls a bit short.

I think the biggest issue here is that the Wireless Extensions API has 
stagnated a bit, and driver writers have gone off and done their own thing 
(for example, WPA support) because the WEAPI hasn't shown leadership in 
this area.  That's fixable, and at this point doesn't seem to be a large 
amount of work since the main offender here is only WPA.

Second, there are, for historical reasons most likely, areas where the 
WEAPI has multiple methods of encoding data to/from user space.  For 
example, WE Quality values and WE Frequency/Channel values.  Quality is 
either signed or unsigned 8-bit number, which (I believe) is either a raw 
dBm/rssi value or a percentage value, respectively.  Frequency uses 
exponent & mantissa notation, OR a channel # stuffed into the 
exponent/mantissa structure.  Things like that.

Comments appreciated, and hopefully this may spark some wider effort to 
get a few things fixed.

So without further ado, here's the list:
-------------------------------------------------------------------------

o  Quality values vary wildly or are absent
   1) atmel doesn't return any quality data from scanned APs
   2) ipw_2100 doesn't return _any_ quality data (as of v1.02)
   3) Different quality methods for almost every driver
      - Prism54 does a quality as a percentage
      - airo mixes use of absolute and relative values in dBm
      - Average and max quality levels for almost all drivers are
         artificial and don't come from the the card in any way

Work Item: normalize quality values.  Wireless extensions supports two
different types of quality data, either percentage or dBm.  PICK ONE.  I 
would recommend reporting only a Percentage value to user space with the 
SIOCGIWSTATS call, and having separate ioctl() calls for getting 
specific dBm/noise values if user-space applications _and_ the driver 
supports it.  We cannot have user-space applications guessing which of 3 
different quality algorithms the driver is reporting.

o  Frequency values vary wildly from iw_get_range
   1) prism54 uses completely different exponent values than airo
   2) airo, atmel, orinoco are the same

Work Item: Normalize frequency values between wireless cards.  Use 
actual frequencies in MHz rather than using Exponent & Mantissa format 
as now.  Force user-space applications to convert channels->frequencies, 
based on what frequencies the driver says it supports. Or, fix drivers 
to report Frequency<->Channel pairs when they report their supported 
frequencies, but the point again is to PICK ONE and make all drivers do 
that.  Remove the guessing-game from user-space and pick one API for 
drivers to use.

o  airo/prism54 seem to have problems with ip6 and cause panic
   1) Some drivers don't NULL out their data after they are done with
      it, causing kernel panics later on down the line.  See Red Hat
      bugzilla #135432 for details, Dave Jones has a patch for the airo
      driver that seems to work better, which is in Red Hat 2.6.10
      kernels.

Work Item: Make sure all drivers dispose of and NULL out their data when 
they close, or fix kernel areas that might depend on that stale data.  
Or whatever the problem is.

o  Not all drivers have correct netlink support, if they even have it
   1) orinoco is too twitchy, sends too many events (shouldn't send them
		during a scan for example)
   2) atmel, airo, and others don't seem to have any netlink support

Work Item: fix all drivers to ensure that when the card successfully 
associates with an access point, that it signals the kernel that its 
network link is "up".

o  Not all drivers support wirless scanning
   1) orinoco driver mainly, support is upstream and is being slowly
      merged into the kernel driver

Work Item: Speed up merge of upstream Orinoco into kernel orinoco

o  Firmware issues
   1) Cisco aironet firmware upload is quite inconsistent, fails with
      5.21 for example.  Firmware <= 5.02 seems to be required for using
      WEP with most access points.  Latest Cisco-provided driver is quite
      different than latest in-kernel driver

Work Item: Figure out licensing issues between Cisco-provided driver for 
2.4 kernel (which is MPL) and in-kernel airo driver (which is GPL).  
Then, figure out what changes were made to the Cisco-provided driver to 
support firmware up to 5.30.17, and make those changes in the in-kernel 
airo driver.

o  Ethtool support for all drivers
   1) viro has done a lot of them, not sure if this is complete.

o  Ad-Hoc mode support is quite flaky or absent from most drivers
   1) prism54 "mgmt tx queue full" errors on otherwise-working cards
   2) madwifi resets bitrate to 0 when switching to ad-hoc mode

Work Item: Fix drivers to support Ad-Hoc mode, attempt to get specs on 
their hardware & registers from manufacturers if we don't have that 
information yet for all "modern" cards.

o  WPA support is lacking or just in-progress, needs much help
   1) The point here is that Wireless Extensions API has severely lagged
      behind the capabilities of current chipsets.  There should be
      support _in_ Wireless Extensions for WPA and its associated
      technologies, instead of what all the drivers do now, which is
      separate, non-standard, private ioctl() calls for WPA settings.

Work Item: standardize on an interface for WPA and its associated 
technologies, and implement that interface in Wireless Extensions API.  
Fix all drivers to use that API rather than private ioctl() calls.  Some 
drivers that support WPA:  atmel, madwifi, prism54, ipw2200.  It would 
also be beneficial in this effort to support the calls that 802.1x 
stacks need (like wpa_supplicant and Open 802.1x) so that they don't 
have to patch the drivers (Open 802.1x) or create special per-driver 
hook modules (wpa_supplicant) to be able to capture the necessary 
authentication packets or set up the card's WPA settings.

o  Drivers deal with hidden ESSIDs differently
   1) ipw2x00 traps " " and runs of \0 and changes it to "<hidden>" in
      the driver, while other drivers just pass the blank string through

Work Item: Standardize all drivers to simply pass an empty string 
through to user-space when the base station does not broadcast its 
ESSID.  Drivers should _not_ be clever about this.


Levels of Importance (my opinion):
1) All drivers _MUST_ support wireless scanning (*cough* orinoco *cough*)
2) WPA support needs to be standardized in Wireless Extensions
3) Consistent (and present) quality data among drivers, both for
    currently connected AP and for scanned APs
4) rtnetlink link notification for all drivers when they associate with
    an AP
5) Ad-Hoc mode support
6) Ethtool support
7) Cisco firmware issues


[-- Attachment #2: Type: TEXT/plain, Size: 5858 bytes --]

What needs to be fixed in Linux 802.11x Wireless:

o  Quality values vary wildly or are absent
   1) atmel doesn't return any quality data from scanned APs
   2) ipw_2100 doesn't return _any_ quality data (as of v1.02)
   3) Different quality methods for almost every driver
      - Prism54 does a quality as a percentage
      - airo mixes use of absolute and relative values in dBm
      - Average and max quality levels for almost all drivers are
         artificial and don't come from the the card in any way

Work Item: normalize quality values.  Wireless extensions supports two
different types of quality data, either percentage or dBm.  PICK ONE.  I 
would recommend reporting only a Percentage value to user space with the 
SIOCGIWSTATS call, and having separate ioctl() calls for getting 
specific dBm/noise values if user-space applications _and_ the driver 
supports it.  We cannot have user-space applications guessing which of 3 
different quality algorithms the driver is reporting.

o  Frequency values vary wildly from iw_get_range
   1) prism54 uses completely different exponent values than airo
   2) airo, atmel, orinoco are the same

Work Item: Normalize frequency values between wireless cards.  Use 
actual frequencies in MHz rather than using Exponent & Mantissa format 
as now.  Force user-space applications to convert channels->frequencies, 
based on what frequencies the driver says it supports. Or, fix drivers 
to report Frequency<->Channel pairs when they report their supported 
frequencies, but the point again is to PICK ONE and make all drivers do 
that.  Remove the guessing-game from user-space and pick one API for 
drivers to use.

o  airo/prism54 seem to have problems with ip6 and cause panic
   1) Some drivers don't NULL out their data after they are done with
      it, causing kernel panics later on down the line.  See Red Hat
      bugzilla #135432 for details, Dave Jones has a patch for the airo
      driver that seems to work better, which is in Red Hat 2.6.10
      kernels.

Work Item: Make sure all drivers dispose of and NULL out their data when 
they close, or fix kernel areas that might depend on that stale data.  
Or whatever the problem is.

o  Not all drivers have correct netlink support, if they even have it
   1) orinoco is too twitchy, sends too many events (shouldn't send them
		during a scan for example)
   2) atmel, airo, and others don't seem to have any netlink support

Work Item: fix all drivers to ensure that when the card successfully 
associates with an access point, that it signals the kernel that its 
network link is "up".

o  Not all drivers support wirless scanning
   1) orinoco driver mainly, support is upstream and is being slowly
      merged into the kernel driver

Work Item: Speed up merge of upstream Orinoco into kernel orinoco

o  Firmware issues
   1) Cisco aironet firmware upload is quite inconsistent, fails with
      5.21 for example.  Firmware <= 5.02 seems to be required for using
      WEP with most access points.  Latest Cisco-provided driver is quite
      different than latest in-kernel driver

Work Item: Figure out licensing issues between Cisco-provided driver for 
2.4 kernel (which is MPL) and in-kernel airo driver (which is GPL).  
Then, figure out what changes were made to the Cisco-provided driver to 
support firmware up to 5.30.17, and make those changes in the in-kernel 
airo driver.

o  Ethtool support for all drivers
   1) viro has done a lot of them, not sure if this is complete.

o  Ad-Hoc mode support is quite flaky or absent from most drivers
   1) prism54 "mgmt tx queue full" errors on otherwise-working cards
   2) madwifi resets bitrate to 0 when switching to ad-hoc mode

Work Item: Fix drivers to support Ad-Hoc mode, attempt to get specs on 
their hardware & registers from manufacturers if we don't have that 
information yet for all "modern" cards.

o  WPA support is lacking or just in-progress, needs much help
   1) The point here is that Wireless Extensions API has severely lagged
      behind the capabilities of current chipsets.  There should be
      support _in_ Wireless Extensions for WPA and its associated
      technologies, instead of what all the drivers do now, which is
      separate, non-standard, private ioctl() calls for WPA settings.

Work Item: standardize on an interface for WPA and its associated 
technologies, and implement that interface in Wireless Extensions API.  
Fix all drivers to use that API rather than private ioctl() calls.  Some 
drivers that support WPA:  atmel, madwifi, prism54, ipw2200.  It would 
also be beneficial in this effort to support the calls that 802.1x 
stacks need (like wpa_supplicant and Open 802.1x) so that they don't 
have to patch the drivers (Open 802.1x) or create special per-driver 
hook modules (wpa_supplicant) to be able to capture the necessary 
authentication packets or set up the card's WPA settings.

o  Drivers deal with hidden ESSIDs differently
   1) ipw2x00 traps " " and runs of \0 and changes it to "<hidden>" in
      the driver, while other drivers just pass the blank string through

Work Item: Standardize all drivers to simply pass an empty string 
through to user-space when the base station does not broadcast its 
ESSID.  Drivers should _not_ be clever about this.


Levels of Importance (my opinion):
1) All drivers _MUST_ support wireless scanning (*cough* orinoco *cough*)
2) WPA support needs to be standardized in Wireless Extensions
3) Consistent (and present) quality data among drivers, both for
    currently connected AP and for scanned APs
4) rtnetlink link notification for all drivers when they associate with
    an AP
5) Ad-Hoc mode support
6) Ethtool support
7) Cisco firmware issues