generic 802.11 stack

[Vladimir Kondratiev <vkondra@mail.ru>]

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

Dave,
I'd like to evaluate possibility to use your stack for real driver. 80211 have 
some specifics thus we need to answer following questions:

- some devices handles almost all MAC in firmware; some - handle control frame 
exchange in firmware, rest - on host; some use other separation of work 
between host and firmware. So, quite flexible mechanism to specify offloading 
of parts of .11 stack to firmware required. What is best way? 
netdev->features?

- there are cases when PHY information needed, to make decisions (like select 
AP from list), or for information purposes (sniffer). What is your vision how 
to do this? I.e. provide some standard PHY header before MAC header, out of 
band (use cb?)
I see the following info that may be interesting:
rate;modulation;preamble;TSF timer;RSSI;antenna;signal;noise;AGC. This list 
may vary from NIC to NIC.

- there is PHY level information that may be needed for Tx:
modulation;rate;retry policy and rates;Tx power;protection(RTS/CTS, CTS to 
self). Same question as above: how to provide it?

- there is some interesting information that may come from Tx status, like 
success indication, last rate, retry count, energy in channel after packet, 
actual backoff time.

- is it feasible to do rate scaling in generic way in stack? Or should it be 
done always in the driver?

- Since WME and TGe introduction, NICs will likely to have multiple Tx queues. 
It would be wise for driver to use multiple Tx queues and start/stop them 
separately, like have all functions netif_start_queue() etc. have additional 
parameter - queue number. Will it fit into your stack?

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