It's high time that Linux get a serious effort going on a generic 802.11
stack, as it seems we are in danger of having every new wireless driver
invent one if we do not.
Given that there are at least 3 complete wireless stacks (or
thereabouts) floating about for Linux, I picked one that I felt had the
best chance of being _evolved_ into a nice, clean, generic wireless
stack: HostAP.
My general hope (plan?) is that generic wireless code can be arrived at
without horribly intrusive changes that require a 2.7 kernel.
wireless-2.6 is targetted for eventual merging, but it won't be
submitted anytime soon.
Now it's time for open source to kick into action :) wireless-2.6 queue
is available in patch form or BitKeeper for review. Or, if you object
to my selection of wireless code, now's the time to speak up.
BTW to Intel Centrino folks -- I would like to merge the current (open
source) Centrino driver into wireless-2.6 as well, to get it more
exposure, and also to ensure that it uses whatever generic 802.11 code
happens to appear...
Oh, and please speak up on netdev@oss.sgi.com, or at least CC there.
Patch:
http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/2.6.7-rc2-bk3-wireless1.patch.bz2
BitKeeper (all of these are equivalent):
bk://kernel.bkbits.net/jgarzik/wireless-2.6
bk://gkernel.bkbits.net/wireless-2.6
http://gkernel.bkbits.net/wireless-2.6 (note: _not_ a Web URL)
Finally, here is Jouni's patch submission message, elaborating on the
driver-specific details:
Finally, here's the first attempt at submitting Host AP code for
wireless-2.6 tree. In addition, this could be considered for merging
into linus-2.5 tree, so review and comments are very much welcome. Host
AP code has lived in an external CVS repository for three years and is
widely used.
The included patch has minimal changes to the current tree (against
2.6.6, but should apply to different versions with some differences in
line numbers) for including a new directory drivers/net/wireless/hostap.
The contents of that new directory is a bit large for a patch file and
since all the files are new, I made it available as a compressed tarball
at http://hostap.epitest.fi/hostap-linux.tgz. This should be untarred in
the root of the kernel tree (i.e., the file paths in the tarball start
with drivers/net/wirelss/hostap/...).
I removed most of the backwards (for Linux 2.4, pcmcia-cs modules,
different wireless extensions versions) compatibility code. In addition,
I replaced integrated implementations of ARC4, Michael MIC, and AES with
crypto API. AES-CCM mode is still implemented in hostap_crypt_ccmp.c,
but it could be moved at some point to crypto API as a new encryption
mode.
On Wed, 02 Jun 2004 23:45:28 -0400
Jeff Garzik [off-list ref] wrote:
Given that there are at least 3 complete wireless stacks (or
thereabouts) floating about for Linux, I picked one that I felt had the
best chance of being _evolved_ into a nice, clean, generic wireless
stack: HostAP.
Even though I authored one of the "other" stacks, I'm totally fine
with this choice. Mainly because I simply lack the time or resources
to continue working on the stack I started.
David S. Miller wrote:
On Wed, 02 Jun 2004 23:45:28 -0400
Jeff Garzik [off-list ref] wrote:
quoted
Given that there are at least 3 complete wireless stacks (or
thereabouts) floating about for Linux, I picked one that I felt had the
best chance of being _evolved_ into a nice, clean, generic wireless
stack: HostAP.
Even though I authored one of the "other" stacks, I'm totally fine
with this choice. Mainly because I simply lack the time or resources
to continue working on the stack I started.
Actually... I want to use some of your stuff too. :) HostAP is a
successful implementation, but your stuff was a good example of the glue
needed to tie 802.11 tightly to the net stack.
HostAP still has some "its a separate driver" stuff it needs to get rid
of, as it is made more generic.
Jeff
I thought I had replied to this, but I don't see it in my sent, drafts,
or on the list... so, I'll recompose and send again.
Jeff Garzik wrote:
It's high time that Linux get a serious effort going on a generic
802.11 stack, as it seems we are in danger of having every new
wireless driver invent one if we do not.
Agreed.
Given that there are at least 3 complete wireless stacks (or
thereabouts) floating about for Linux, I picked one that I felt had
the best chance of being _evolved_ into a nice, clean, generic
wireless stack: HostAP.
This is the path that ipw2100 has been following; we have taken a
snapshot of the Host AP code and have generalized the Tx/Rx stacks to
remove all HW specific fields and structures so we can use them for the
ipw2100 and (eventually) the ipw2200 project.
We currently have a HW independent stack that should work for any
underlying card that can Tx/Rx 802.11 data frames. This stack is based
on Host AP 0.1.3 (Pedro Ramalhais has since written a patch for ipw2100
that will update it to using the Host AP CVS)
The stack we have is not as complete as the original Host AP project --
portions of the code (specifically those aspects which I can't test or
leverage w/ the HW I have) have been wrapped in #ifdef/#endif blocks
(pretty much everything dealing with master mode).
As we've been trying to track down some ipw2100 project defects we've
been liberal in throwing some ipw2100 specific checks into the
ieee80211_* files, but those are easily removed. Also a result of that
defect tracking there is some code in those files that just needs to be
cleaned up/removed.
My general hope (plan?) is that generic wireless code can be arrived
at without horribly intrusive changes that require a 2.7 kernel.
wireless-2.6 is targetted for eventual merging, but it won't be
submitted anytime soon.
Performance optimizations for wireless may be a bit more intrusive, but
are not required (AFAIK) to get a generic stack with performance and
features equivelant to what is currently enabled by the various drivers
available.
<snip>
BTW to Intel Centrino folks -- I would like to merge the current (open
source) Centrino driver into wireless-2.6 as well, to get it more
exposure, and also to ensure that it uses whatever generic 802.11 code
happens to appear...
I would like to get a couple stability issues resolved before we
incorporate the ipw2100 driver into the wireless-2.6 set.
For those that are curious, the current work plan for the ipw2100 is
(roughly):
0) Fix fragmentation in the current ieee80211_* Tx/Rx stack
1) Generalize the management frame handling (as much as is currently
required) into ieee80211_*
2) Extract the ieee80211_* code so that it can be compiled into the
kernel separate from ipw2100 (either as a module or static)
3) Create a patchset for the wireless extension interface to support
what's needed to configure algos and keys (based in part on what is done
in Host AP and other drivers). Also provide a patchset for the user
space tools. Hopefully that will kick off lots of discussion :)
During all of the above we will also be working to fix existing
stability and feature issues. Main issues here deal with a data
corruption issue during C3 processor transitions as well as random
stalling of SSL connections.
James