Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
soc:2009:oremanj:project_plan:start [2009/06/02 00:46] rwcr |
soc:2009:oremanj:project_plan:start [2009/06/25 15:47] (current) mdc gPXE-isation :) |
||
|---|---|---|---|
| Line 2: | Line 2: | ||
| ===== Project Plan ===== | ===== Project Plan ===== | ||
| - | |||
| ==== Summary ==== | ==== Summary ==== | ||
| - | I will design an infrastructure for 802.11 cards to be used by Etherboot, 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. | + | 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. |
| ==== Outline ==== | ==== Outline ==== | ||
| My work will have three parts: | 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. | + | * 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. | + | * 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. | + | * 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 [[..:notes:design|design notes]] (still in progress) going into further detail. | I have compiled some [[..:notes:design|design notes]] (still in progress) going into further detail. | ||
| Line 17: | Line 16: | ||
| * Ad-hoc mode ("computer-to-computer network" or IBSS, operating without an access point) - a little preconfiguration is expected in network booting. | * 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. | * 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) | + | * 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 these on wired networks either, and they're a pain. | + | * 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. | * 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. | * Various other technologies that in practice aren't necessary for a light 802.11 implementation: frequency hopping, channel agility, APSD, block ACK, etc. | ||
| Line 32: | Line 31: | ||
| 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 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: probably physics olympiad | + | 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. | 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. | ||
