Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack

[Vladimir Kondratiev <vkondra@mail.ru>]

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

On Wednesday 29 September 2004 02:48, Luis R. Rodriguez wrote:
LR> On Tue, Sep 28, 2004 at 10:29:48PM +0200, Vladimir Kondratiev wrote:
LR> > On Tuesday 28 September 2004 14:20, Luis R. Rodriguez wrote:
LR> > LR> RFC: what are the chances we can implement our own generic
 "softmac" that may LR> > LR> be usable by the different chipsets out there?
LR> >
LR> > Coming days, I will submit "framework" consisting of stack based on
 Dave's LR> > code and debug driver which will be able to imitate Rx. I have
 working basic LR> > Tx/Rx. Then, I'd like to concentrate on interfaces
 stack-driver and LR> > stack-upper layers. It would be great if someone will
 do MAC algorithms. I'll LR> > appreciate this for sure.
LR>
LR> But would it be possible? Would it work, if we write our own softmac
LR> interface? Or are softmac interaces/libraries strictly dependent on a
LR> chipset being used?
LR>
LR>  Luis
LR>
In idea yes, 802.11 stack should serve any low level driver provided it can 
Tx/Rx 802.11 frames. Just like Ethernet, where driver is very simple. The 
difference is, 802.11 stack is not written yet, we need to make sure we do it 
in smart way and with reasonable assumptions about what low level driver can 
do.

Thus far, I assume, low level driver (and NIC, of course) can:
-Tx/Rx arbitrary data and management packets. Control frames generated by NIC.
-NIC can perform scanning and report beacons or probe resp. to the stack.
-NIC can report some basic PHY data per packet: rate, RSSI, maybe something 
else.
-NIC accept some basic PHY data per packet on Tx: rate, retry count, 
protection, maybe Tx power and some others
-NIC can do crypto transformations on both Tx and Rx. For this, crypto key 
need be provided per packet for Tx and some ,mechanism to provide key for 
each peer need to be established for Rx.
-NIC may choose to not do fragmentation/reassembly, stack will handle it.
-NIC may have many Tx queues for QoS, it will be able to start/stop each one.

To not raise unsupported expectations: 802.11 stack is only skeleton for now. 
I will do interface parts first. For actual algorithms to handle managements 
flows, help required. But, I believe it is wise to write these algorithms 
once for this stack rather to implement whole stack with each driver.

Vladimir.

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