This is an old revision of the document!
====== Joshua Oreman: 802.11 wireless development ====== ===== Journal Week 3 ===== ==== Monday, 8 June ==== **It's ALIIIIIVE!** After a long day of head-scratching and bug-squashing, I've gotten the wireless to work in my test system with no apparent problems. :-) First, the commits: * [[http://git.etherboot.org/?p=people/oremanj/gpxe.git;a=commit;h=44dc8f43a277c84afe6e31c0906fc08acc386748| [drivers rtl8180] Debugging tweaks, decrease ring size, ignore DMA errors]] * [[http://git.etherboot.org/?p=people/oremanj/gpxe.git;a=commit;h=cf950f4e53e32ee74e02c8ba5d2bc8da93868738| [netdevice] Adjust maximum link-layer header length for 802.11]] (then merged with mainline and resolved the conflict) * [[http://git.etherboot.org/?p=people/oremanj/gpxe.git;a=commit;h=255f3fdc6c75ca8419f75748f62412d5fb69a55f| [dhcp] Await link-up before starting DHCP]] * [[http://git.etherboot.org/?p=people/oremanj/gpxe.git;a=commit;h=8182fff820119754b78c3ec8ed6f4de7884777e1| [802.11] Bugfix and minor improvement potpourri]] Also, the obligatory screenshot: {{..:gpxe-wifi-load.jpg?160x120|gPXE loading a script over 802.11}} I've successfully loaded both the "smoke test" script in that screenshot, and the [[http://etherboot.org/gtest/gtest.gpxe|more rigorous gtest.gpxe]] that loads tomsrtbt. Load time for the latter was about 57 seconds from "dhcp net0" to "Uncompressing Linux...", including the time it took for me to type the "chain" command. Compared to 47 seconds on the wired rtl8139 NIC in the same box, which didn't have to go through a 5-second network probe sequence, that's not too bad. The DMA issue I noted on Sunday turned out to be more or less a false alarm. Upon checking the Linux driver I discovered that it simply ignores those DMA_FAIL errors (drops the packet with no record thereof), and when I modified my code to do the same (and fixed a bunch of bugs in the MAC layer), everything was able to work. It may be that we're suffering in performance due to all the errors, and that they could be fixed by some configuration setting, but as Realtek won't give up a datasheet and no other open-source OS has drivers I could compare with, this is the best I can do for now. My working hypothesis is that DMA_FAIL might have been overloaded to apply also to "the radio gave me garbage for this one" scenarios. Things left to do on 802.11 include: * [easy] Provide CTS protection if the network asks for it; required for 802.11 g/b interoperability. * [easy] If we don't get a response to our assoc/auth packets within a few seconds during the association phase, resend them. * [easy, added 6/10] If we're running without a user-specified SSID, and we can't associate with the best-signal network due to e.g. encryption, try the others. Possibly extend this to trying others if we get a DHCP that doesn't provide PXE options. * [easy] Provide command-line facilities to see what the card's doing, or extend `ifstat' to show it. (Channel, BSSID, signal strength, etc; this stuff can be very useful for network debugging.) Possibly provide a facility to scan for all networks (one way of doing that is prototyped in net80211.h, but I haven't implemented it). * [easy] Include error message tables for the 802.11 status and reason codes. These would be rather big, but "association denied - status 12" is of no help to anyone who doesn't have the 802.11 standard on hand. Perhaps we should just teach them to gpxebot, and/or figure out a way to encode them into the 32-bit return code space. * [medium] Provide some means of intelligent rate control (decrease rate if we're dropping a lot of packets, cautiously increase it if things seem to be going swimmingly). * [hard] Encryption. * [hard] Driver for ath5k cards (very common, very powerful chipset with a cooperative manufacturer). Maybe more drivers than that if I have time, but ath5k is quite a bit more complicated than rtl8180/8185. It probably goes without saying, but I'm really excited about this. :-) I probably won't be doing much work on gPXE tomorrow, because I have to catch up on some other things and I'd like to see some other people successfully test this before I forge boldly ahead. ==== Tuesday-Wednesday, 9-10 June ==== No commits - I had some non-gPXE things I had to catch up on, and was doing setup for later work. I now have a kernel and hostapd configuration that will let me configure my development box with all sorts of strange wireless setups, so I can test them under gPXE. This will come in especially handy for encryption. I think I'll try and knock off the above bunch of "easy" tasks tomorrow, pending discussion with mdc and/or mcb30.
