**This is an old revision of the document!** ----

A PCRE internal error occured. This might be caused by a faulty plugin

====== Joshua Oreman: 802.11 wireless development ====== ===== gPXE 802.11 API design notes ===== The below are my thoughts about a week into the coding season. They may change without warning. This is not meant to be a complete API guide; there are comments in the header files for that. 802.11 drivers should "feel" like regular NIC drivers. They'll need to handle more things, because wireless networking is more complex than wired, but the programming interface should be similar. 802.11 has a lot of MAC-layer processing, though, so there needs to be a shim between the driver layer and the ll_protocol push/pull. I chose to implement this by creating a ''net80211_device'', and having the 802.11 MAC layer set up a normal ''net_device'' to wrap it. The operations for a ''net80211_device'' are the same as those of a ''net_device'', with one addition: ''config()''. The ''config'' call is used to ask the driver to update any hardware-level settings for wireless-specific issues like channel, transmission rate, association settings (what network are we connected to?), and physical-layer issues like ERP parameters. (When associating with an 802.11g network, we might get something in the association response packet that tells us how to configure our timings and such; the card needs to hear about that.) On initialization (the ''probe()'' routine), each wireless driver provides some information about the capabilities and quirks of its hardware in order to register its ''net80211_device''. This information is stored in a ''net80211_hw_info'' structure, and its contents are mostly self-explanatory. The MAC layer uses it to know what to advertise when associating with a network, how to interpret the card's status, and how to set up the wrapping ''net_device'' (proper MAC address). //To be continued...//


QR Code
QR Code soc:2009:oremanj:notes:design (generated for current page)