Joshua Oreman: 802.11 wireless development

I will design an infrastructure for 802.11 cards to be used by gPXE, and as many drivers for it as I have time for. Currently there is only one driver for any 802.11 device (prism2) and it's out-of-date and unsupported by any 802.11 infrastructure. My work will create that infrastructure, with the hopeful end result of a slim 802.11 layer that is versatile enough to support all common use cases and more driver development. I will implement at least one driver, probably two and maybe three, along with generic support for 802.11 features such as security (at least WEP and WPA Personal; WPA Enterprise is much more involved and probably out of this summer's scope) and scanning for available networks.

My work will have three parts:

• An 802.11 MAC layer, sitting between the link-layer protocol and the driver. It will handle the low-level aspects of 802.11 support: associating with a given network, managing parameters like transmission speed and RF usage, handling encryption for networks that need it, reassembling fragmented frames, and so forth.
• One or more drivers for specific families of 802.11 cards. In order from most to least readily supported, I own cards with Realtek 8185, Atheros, and Broadcom chipsets (Linux drivers rtl8180, ath5k, b43). I will work on the drivers in that order, and save drivers past the first until after I have a good set of general 802.11 features complete.
• Extensions to gPXE's command interface to allow the 802.11 layer to be configured. The user needs to be able to set parameters like the SSID to associate with, the encryption key to use, and so forth; ideally there would also be a “site survey” function to choose the closest available network in autoboot circumstances where an SSID hasn't been configured. Although these scanning functions will need to examine 802.11 management frames, it is my intention to write them separately from the 802.11 MAC layer as a matter of good design and future expandability.

I have compiled some design notes (still in progress) going into further detail.

In gPXE's environment there are certain 802.11 features which simply don't make much sense; not to mention, implementing the full 802.11 specification with all its bells and whistles and 15+ major amendments to date would take rather more than a summer! As such, there are some aspects of the standard which I have decided to forgo, at least for the moment:

• Ad-hoc mode (“computer-to-computer network” or IBSS, operating without an access point) - a little preconfiguration is expected in network booting.
• Master mode (gPXE is an access point itself) or monitor mode (passive network scanning) - people can boot Linux if they want to do those things.
• Detailed regulatory code - it isn't worth the size the databases would take up; gPXE will take regulatory parameters from the access point's beacon frames, making it impossible to associate with a “hidden SSID” network on the 5GHz band (a real regulatory mess; 2.4GHz is fine)
• Quality of Service and Contention-Free Polling network enhancements - as far as I'm aware we don't support QoS on wired networks either, and it's a pain.
• Spectrum Management on the 5GHz band - it's theoretically required on certain channels in certain countries to avoid interfering with satellite communications, but it's something we can fairly easily add later if we need to.
• Various other technologies that in practice aren't necessary for a light 802.11 implementation: frequency hopping, channel agility, APSD, block ACK, etc.

I am open to implementing any of these, during the summer if I have time or later if not, if a compelling use case and argument is demonstrated.

Weeks 1-3: Bare-bones infrastructure and one driver. I will make an 802.11 MAC layer with no support for encryption or user configuration - just sending and receiving packets on a hardcoded SSID - and a driver for a wireless PCI card that will allow me to test it. I intend to have both parts of this nominally done by the end of Week 2 or the beginning of Week 3, leaving a few days for hunting down the inevitable bugs that will crop up. By the end of Week 3, I intend to be able to netboot over WiFi. The rest of the summer will be spent making that process more stable and more versatile.

Weeks 4-5: Cleanup and UI. Basically, I'll use the first half of the summer getting the 802.11 support to a place where the average user (if he has the type of card I do) could reliably configure gPXE to boot over an unencrypted wireless network. The UI changes alone shouldn't take long at all, but I'm allotting extra time for exterminating the inevitable bugs that surface when driver code is involved. If I'm lucky in the bug department, I'll be able to move to the next phase sooner than Week 6.

Weeks 6, 9-10: Useful WiFi features, which right now means support for encryption and a site survey (list all wireless networks around here). Encryption support is essential because of how many wireless networks use it, while a site survey is more “would be nice” for autoconfiguration or command-line convenience.

Weeks 7-8 (July 5-20) will be low-activity because I will be competing in the International Physics Olympiad. I have OK'ed this with the mentors and will do my best to accomplish at least the amount finished by the typical SoC student in an open summer.

Remaining time: If all's gone well so far, and I've got at least a couple of weeks left (depending on how hard it was for me to do the first one), implement another driver, for the ath5k Atheros chipset in fairly common use. If all's not gone well, fix the parts that aren't working. Clean up code, document, test, etc.