163 lines
7.5 KiB
Plaintext
163 lines
7.5 KiB
Plaintext
|
What this layer should do
|
||
|
|
||
|
- It mantain the old mechanism as alternative, so the
|
||
|
ipw2100 driver works with really few changes.
|
||
|
- Encapsulate / Decapsulate ieee80211 packet
|
||
|
- Handle fragmentation
|
||
|
- Optionally provide an alterantive mechanism for netif queue stop/wake,
|
||
|
so that the ieee80211 layer will pass one fragment per time instead of
|
||
|
one txb struct per time. so the driver can stop the queue in the middle
|
||
|
of a packet.
|
||
|
- Provide two different TX interfaces for cards that can handle management
|
||
|
frames on one HW queue, and data on another, and for cards that have only
|
||
|
one HW queue (the latter untested and very, very rough).
|
||
|
- Optionally provide the logic for handling IBSS/MASTER/MONITOR/BSS modes
|
||
|
and for the channel, essid and wap get/set wireless extension requests.
|
||
|
so that the driver has only to change channel when the ieee stack tell it.
|
||
|
- Optionally provide a scanning mechanism so that the driver has not to
|
||
|
worry about this, just implement the set channel calback and pass
|
||
|
frames to the upper layer
|
||
|
- Optionally provide the bss client protocol handshaking (just with open
|
||
|
authentication)
|
||
|
- Optionally provide the probe request send mechanism
|
||
|
- Optionally provide the bss master mode logic to handle association
|
||
|
protocol (only open authentication) and probe responses.
|
||
|
- SW wep encryption (with open authentication)
|
||
|
- It collects some stats
|
||
|
- It provides beacons to the card when it ask for them
|
||
|
|
||
|
What this layer doesn't do (yet)
|
||
|
- Perform shared authentication
|
||
|
- Have full support for master mode (the AP should loop back in the air
|
||
|
frames from an associated client to another. This could be done easily
|
||
|
with few lines of code, and it is done in my previous version of the
|
||
|
stach, but a table of association must be keept and a disassociation
|
||
|
policy must be decided and implemented.
|
||
|
- Handle cleanly the full ieee 802.11 protocol. In AP mode it never
|
||
|
disassociate clients, and it is really prone to always allow access.
|
||
|
In bss client mode it is a bit rough with AP deauth and disassoc requests.
|
||
|
- It has not any entry point to view the collected stats.
|
||
|
- Altought it takes care of the card supported rates in the management frame
|
||
|
it sends, support for rate changing on TXed packet is not complete.
|
||
|
- Give up once associated in bss client mode (it never detect a
|
||
|
signal loss condition to disassociate and restart scanning)
|
||
|
- Provide a mechanism for enabling the TX in monitor mode, so
|
||
|
userspace programs can TX raw packets.
|
||
|
- Provide a mechanism for cards that need that the SW take care of beacon
|
||
|
TX completely, in sense that the SW has to enqueue by itself beacons
|
||
|
to the card so it TX them (if any...)
|
||
|
APIs
|
||
|
|
||
|
Callback functions in the original stack has been mantained.
|
||
|
following has been added (from ieee80211.h)
|
||
|
|
||
|
/* Softmac-generated frames (mamagement) are TXed via this
|
||
|
* callback if the flag IEEE_SOFTMAC_SINGLE_QUEUE is
|
||
|
* not set. As some cards may have different HW queues that
|
||
|
* one might want to use for data and management frames
|
||
|
* the option to have two callbacks might be useful.
|
||
|
* This fucntion can't sleep.
|
||
|
*/
|
||
|
int (*softmac_hard_start_xmit)(struct sk_buff *skb,
|
||
|
struct net_device *dev);
|
||
|
|
||
|
/* used instead of hard_start_xmit (not softmac_hard_start_xmit)
|
||
|
* if the IEEE_SOFTMAC_TX_QUEUE feature is used to TX data
|
||
|
* frames. I the option IEEE_SOFTMAC_SINGLE_QUEUE is also set
|
||
|
* then also management frames are sent via this callback.
|
||
|
* This function can't sleep.
|
||
|
*/
|
||
|
void (*softmac_data_hard_start_xmit)(struct sk_buff *skb,
|
||
|
struct net_device *dev);
|
||
|
|
||
|
/* stops the HW queue for DATA frames. Useful to avoid
|
||
|
* waste time to TX data frame when we are reassociating
|
||
|
* This function can sleep.
|
||
|
*/
|
||
|
void (*data_hard_stop)(struct net_device *dev);
|
||
|
|
||
|
/* OK this is complementar to data_poll_hard_stop */
|
||
|
void (*data_hard_resume)(struct net_device *dev);
|
||
|
|
||
|
/* ask to the driver to retune the radio .
|
||
|
* This function can sleep. the driver should ensure
|
||
|
* the radio has been swithced before return.
|
||
|
*/
|
||
|
void (*set_chan)(struct net_device *dev,short ch);
|
||
|
|
||
|
/* These are not used if the ieee stack takes care of
|
||
|
* scanning (IEEE_SOFTMAC_SCAN feature set).
|
||
|
* In this case only the set_chan is used.
|
||
|
*
|
||
|
* The syncro version is similar to the start_scan but
|
||
|
* does not return until all channels has been scanned.
|
||
|
* this is called in user context and should sleep,
|
||
|
* it is called in a work_queue when swithcing to ad-hoc mode
|
||
|
* or in behalf of iwlist scan when the card is associated
|
||
|
* and root user ask for a scan.
|
||
|
* the fucntion stop_scan should stop both the syncro and
|
||
|
* background scanning and can sleep.
|
||
|
* The fucntion start_scan should initiate the background
|
||
|
* scanning and can't sleep.
|
||
|
*/
|
||
|
void (*scan_syncro)(struct net_device *dev);
|
||
|
void (*start_scan)(struct net_device *dev);
|
||
|
void (*stop_scan)(struct net_device *dev);
|
||
|
|
||
|
/* indicate the driver that the link state is changed
|
||
|
* for example it may indicate the card is associated now.
|
||
|
* Driver might be interested in this to apply RX filter
|
||
|
* rules or simply light the LINK led
|
||
|
*/
|
||
|
void (*link_change)(struct net_device *dev);
|
||
|
|
||
|
Functions hard_data_[resume/stop] are optional and should not be used
|
||
|
if the driver decides to uses data+management frames enqueue in a
|
||
|
single HQ queue (thus using just the softmac_hard_data_start_xmit
|
||
|
callback).
|
||
|
|
||
|
Function that the driver can use are:
|
||
|
|
||
|
ieee80211_get_beacon - this is called by the driver when
|
||
|
the HW needs a beacon.
|
||
|
ieee80211_softmac_start_protocol - this should normally be called in the
|
||
|
driver open function
|
||
|
ieee80211_softmac_stop_protocol - the opposite of the above
|
||
|
ieee80211_wake_queue - this is similar to netif_wake_queue
|
||
|
ieee80211_reset_queue - this throw away fragments pending(if any)
|
||
|
ieee80211_stop_queue - this is similar to netif_stop_queue
|
||
|
|
||
|
|
||
|
known BUGS:
|
||
|
- When performing syncro scan (possiblily when swithcing to ad-hoc mode
|
||
|
and when running iwlist scan when associated) there is still an odd
|
||
|
behaviour.. I have not looked in this more accurately (yet).
|
||
|
|
||
|
locking:
|
||
|
locking is done by means of three structures.
|
||
|
1- ieee->lock (by means of spin_[un]lock_irq[save/restore]
|
||
|
2- ieee->wx_sem
|
||
|
3- ieee->scan_sem
|
||
|
|
||
|
the lock 1 is what protect most of the critical sections in the ieee stack.
|
||
|
the lock 2 is used to avoid that more than one of the SET wireless extension
|
||
|
handlers (as well as start/stop protocol function) are running at the same time.
|
||
|
the lock 1 is used when we need to modify or read the shared data in the wx handlers.
|
||
|
In other words the lock 2 will prevent one SET action will run across another SET
|
||
|
action (by make sleep the 2nd one) but allow GET actions, while the lock 1
|
||
|
make atomic those little shared data access in both GET and SET operation.
|
||
|
So get operation will be never be delayed really: they will never sleep..
|
||
|
Furthermore in the top of some SET operations a flag is set before acquiring
|
||
|
the lock. This is an help to make the previous running SET operation to
|
||
|
finish faster if needed (just in case the second one will totally undo the
|
||
|
first, so there is not need to complete the 1st really.. ).
|
||
|
The background scanning mechaninsm is protected by the lock 1 except for the
|
||
|
workqueue. this wq is here just to let the set_chan callback sleep (I thinked it
|
||
|
might be appreciated by USB network card driver developer). In this case the lock 3
|
||
|
take its turn.
|
||
|
Thus the stop function needs both the locks.
|
||
|
Funny in the syncro scan the lock 2 play its role (as both the syncro_scan
|
||
|
function and the stop scan function are called with this semaphore held).
|
||
|
|
||
|
|