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.
- Although 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).
5a0e3ad6af