Re: generic 802.11 stack

[James Ketrenos <jketreno@linux.intel.com>]

David S. Miller wrote:

>On Sun, 12 Sep 2004 20:09:08 -0400
>Jeff Garzik <jgarzik@pobox.com> wrote:
>  
>
>>Vladimir Kondratiev wrote:
>>    
>>
>>>To inform about status:
>>>I started to work on idea of 802.11 generic stack. I start from code by Dave. 
>>>This far I fixed it to compile for 2.6 (Makefile and couple of syntax 
>>>errors).
>>>I am going to implement minimum functionality, at this stage I will somehow 
>>>publish the project. Anyone can suggest what it the right solution for 
>>>hosting? Sourceforge? Something else?
>>>      
>>>
>>I can put it into the wireless-2.6 queue, which is where I would prefer 
>>that work on a generic 802.11 stack went.
>>    
>>
>
>This is fine with me as well.
>  
>
I have seen two paths that need to occur:

1) Creation of a generic 802.11 frame handling stack (management, data, 
etc.) sufficient to do .3 to .11 conversion, .11 fragmentation, state 
machine, etc.
2) Tight integration of a .11 stack into the kernel

The first step can occur with minimal changes to the rest of the 
kernel,  isolated completely within drivers/net/wireless.  Once a stack 
is there, all the drivers there can be adapted to use that.  This would 
seem reasonable to pull into the 2.6 stable series.

The second step will likely require more invasive changes to other parts 
of the networking stack and I hadn't thought such changes would be 
considered for 2.6.

Am I incorrect in the above?

We have been cleaning up the ipw2200/ipw2100 and their corresponding 
ieee80211 stack so that it could then be used with the other wifi 
drivers (adapting it to add back in features from HostAP that are 
currently stub'd out) in a non-intrusive way (we would like to get ipw* 
merged in soon).  We have a bk tree for this cloned from wireless-2.6 
avialable at ipw.bkbits.net/ipw-2.6.

Right now a driver can register with netdev's xmit to receive the 
ethernet frame and then pass it to ieee80211_skb_to_txb() to transform 
it into a chain of 802.11 fragments (encrypted if configured to do so) 
which the device can then pass to the HW.  I don't like the way the 
skb_to_txb transform occurs, but its working right now.  The next level 
of integration would be to have the device driver register an ieee80211 
stack callback as the xmit handler, and then register a .11 xmit with 
the ieee80211 stack.

Anyway, based on what I had read previously on this group, the sequence 
of steps I understood needing to be followed were:

0) Get the ipw2100 and ipw2200 drivers functionally complete so that end 
users can fully utilize that hardware.
1) Create generic ieee80211 frame handling stack.  HW specific piece 
should be limited to Tx/Rx of raw frames as much as possible (while 
supporting drivers that can not do full 802.11 frame tx/rx).  For 
nonintrusive inclusion in kernel, this would be achieved through calls 
into the ieee80211 stack from the driver vs. addition of netdev entry 
points.  To date this has been achieved by adding infrastructure into 
either the ipw2100 or ipw2200 project, then merging it into ieee80211 so 
that the other project could leverage it.
2) Adapt other drivers besides ipw2100 and ipw2200 to use the stack
3) Once 1 and 2 are stabilized, begin restructuring the entry points to 
more tightly integrate the .11 handling into the netdev core.

One area where I wasn't sure on how invasive it would be for stack 
optimizations deal with 802.11 fragmentation and encryption of said 
fragments such that TCP retries do not require 
re-fragmentation/encryption when host based enc/frag is enabled.

The next potentially invasive area is the addition of TGe support which 
Vladimir has discussed previously.

We based the current ieee80211 stack in part on the Host AP stack.  In 
looking through the madwifi stack, there are traights that it carries 
that would be nice to be able to use as well moving forward -- whether 
through code (CVS madwifi is licensed under a GPL compatible BSD 
license) or aspects of design. 

The whole of the ieee80211 stack (and ipw2100/ipw2200 drivers) are 
licensed under GPL version 2.

James