This is an old revision of the document!
====== Joshua Oreman: 802.11 wireless development ====== ===== Journal Week 5 ===== ==== Monday, 29 June ==== Meeting notes from last Saturday: * alloc_iob() should align to the smallest power of two greater than the allocation size, instead of the current constant of 2kb, to make sure allocations don't cross a page boundary for finicky cards. 802.11 packets can be larger than 2kb, so this is the first time it's come up. * Discussed implementing a proper cryptographic RNG, possibly using the low-order bits of the TSC on timer interrupts; for now I've just stubbed the relevant function to use random(). * I'm going to try to get WPA1 with TKIP working by the middle of the week; hopefully WPA2 with CCMP by the end. * I leave Sunday for the IPhO, so I want to get as much done as I can before that :-) * My [[..:notes:modules|loadable module idea]] was vastly overcomplicated; one can get the same effect just by chainloading another gPXE. * It may be a good idea to either turn gPXE into a bzImage (it's currently a low-loaded zImage) or decrease the amount of heap/stack we give to zImages, as my test machine serves as an example of one whose EBDA goes all the way down to 0x98c00 and prevents loading zImage kernels using gPXE. Commits: * [[http://git.etherboot.org/?p=people/oremanj/gpxe.git;a=commit;h=f88f20d617c740c9d62b092a0230db17d890ed19| [802.11] Make wpa.h global, remove eapol_key.h]] * [[http://git.etherboot.org/?p=people/oremanj/gpxe.git;a=commit;h=fa77809958e3de729990c056eb1d30a092ad7356| [crypto] Add a placeholder for a proper random number generator]] * [[http://git.etherboot.org/?p=people/oremanj/gpxe.git;a=commit;h=230cd55eac8f81f31787fb5b484a36d25be9a546| [sha1] Parameter type cleanup]] * [[http://git.etherboot.org/?p=people/oremanj/gpxe.git;a=commit;h=9cdf468e489c9f112a2a90b0e8dc9cf8a8eabd3e| [802.11] Extensions of core code to make WPA more readily supportable]] * [[http://git.etherboot.org/?p=people/oremanj/gpxe.git;a=commit;h=3e12e451ead722a85e7cd6dd31195936ac8f1411| [802.11] Clarify some RSN definitions]] * [[http://git.etherboot.org/?p=people/oremanj/gpxe.git;a=commit;h=2d45fee0cd5b695983a871a312a436531bc6e69f| [eap] Try eap-identity setting before username]] * [[http://git.etherboot.org/?p=people/oremanj/gpxe.git;a=commit;h=fae195f05e7ce53258a5c7c628dac0f462cb461c| [eapol] Properly free packet we now own, if callback fails]] * [[http://git.etherboot.org/?p=people/oremanj/gpxe.git;a=commit;h=636dcf67a3b5a08265654b586702bd00f5e48bd0| [802.11] Implement WPA 4-Way Handshake and Group Key Handshake]] The last one is the biggie; it represents about 3/4 of the work necessary to get WPA done. The rest is just in the routine to encrypt or decrypt an individual packet. (I also have to write the encryption and decryption functions for the key data in the 4-Way Handshake frames.) I'm going to try to get TKIP encryption coded tomorrow, so I can have Wednesday to test it. If all goes well, CCMP later in the week. ==== Tuesday, 30 June ==== * [[http://git.etherboot.org/?p=people/oremanj/gpxe.git;a=commit;h=d387838da36d744327715ca4def419cf4bdbfd62| [crypto] Add parentheses around len argument in blocksize assert]] * [[http://git.etherboot.org/?p=people/oremanj/gpxe.git;a=commit;h=fc41feef104690b07abf5b3a290260d4625fad93| [crypto] Add arc4_skip() to perform ARC4 skipping some keystream bytes]] * [[http://git.etherboot.org/?p=people/oremanj/gpxe.git;a=commit;h=363f832a6977c8fea4d13c857afae43478e19156| [802.11] Make IE processing more robust]] * [[http://git.etherboot.org/?p=people/oremanj/gpxe.git;a=commit;h=149c55b5c98f73902a2462e9c3a6daee14788133| [802.11] Pass initial RSC to sec80211_install()]] * [[http://git.etherboot.org/?p=people/oremanj/gpxe.git;a=commit;h=5e06bec67cf4e97e484c2758f564fd5d84beecb0| [wpa] Add replay detection, miscellaneous other fixes]] * [[http://git.etherboot.org/?p=people/oremanj/gpxe.git;a=commit;h=97c5705425ce91c65fccaffce115667f4a018dc7| [wpa] Add PSK frontend and TKIP cryptosystem support]] Theoretically, WPA support [for TKIP and PSK, which are the most common cipher and AKM used] is now complete! In practice it's probably got some serious bugs, but that's what testing tomorrow is for. :-) ==== Wednesday, 1 July ==== * [[http://git.etherboot.org/?p=people/oremanj/gpxe.git;a=commit;h=9813b562861099a58de1dc769a418844ec67c6f5| [crypto] Properly provide last block of SHA1 PRF data]] * [[http://git.etherboot.org/?p=people/oremanj/gpxe.git;a=commit;h=9f6aaab6f95c78910d057e32e3408196e32873ab| [rtl818x] Keep device pointer for later cleanup]] * [[http://git.etherboot.org/?p=people/oremanj/gpxe.git;a=commit;h=fad84bae86d3ae983a5ae00ed671f5f57a66796d| [eapol] Record protocol field in network byte order]] * [[http://git.etherboot.org/?p=people/oremanj/gpxe.git;a=commit;h=d2d44ba47beee86f6fea8071dfb4003cbca990bc| [802.11] WPA bugfix potpourri]] It works! I was able to use gPXE's new WPA support to connect to an access point configured to use either WPA or WPA2-format packets, with TKIP as the cryptosystem. WPA2 also supports a more secure and complex cryptosystem called CCMP, based on AES; hopefully I'll be able to implement it by the end of the week. WPA is quite a complex system, and I'm very glad I was able to get it to work. If you want to get an idea of the stuff it's managing, you can compile with ''DEBUG=net80211:3,sec80211:3,wpa:3,wpa_tkip:3,wpa_psk''; since I used ''DBGC()'', the result is rather psychedelic :-) ==== Thursday, 2 July ==== No code today; I needed to get caught up with my physics preparation, and had some other issues to take care of. I did have an impromptu meeting with the mentors this morning, which Marty suggested upon Michael's statement that he couldn't make our usual Saturday time. * Since I've completed (as of tomorrow) all the core wireless features I originally proposed, we discussed future plans. * Drivers: * I'll write a driver for ''ath5k'' (Atheros non-802.11n cards); they're quite widespread and are one of the few chipsets in common use that don't require custom firmware, so ath5k gPXE could feasibly be burned to a (larger than normal) EEPROM. * JH suggested support for the various Intel wireless drivers, as they're used for the built-in wireless on Centrino laptops. These do require firmware, though. * A USB wireless driver would be handy, but a USB stack is a little out-of-scope for the time I've got left in the summer :-) * Since we're certainly going to wind up with some wireless drivers requiring firmware files, how do we handle the firmware? * It seems most straightforward to treat them like all the other binary blobs we deal with, as images. That way they can be embedded. * One could either use an embedded image for firmware, or supply it to a ''.lkrn''-prefix gPXE as an initrd (using an eventual patch to support that). There would need to be some way of identifying it, and these files almost never have magic numbers. If we treat firmwares as embedded images always, we could add a field to the embedded image structure to override detected type, and have firmware-type never be autodetected. Another detection possibility is using file extensions; almost every firmware I've ever seen has an extension of ''.fw'', ''.bin'', or ''.ucode'', with ''.fw'' being the most common. We could also wrap firmwares with a gPXE-specific header, but that's cumbersome. * If we go the embedded-image route, which seems likely, we can do things reasonably elegantly: * Extend the embedded image support to use a linker table, so multiple files can contain embedded images. * Have the gPXE build system treat everything in ''firmware/'' with a non-''.c'' extension as a vendor-supplied firmware, and make a ''.c'' file out of it in the same way as ''embedded.c'' is made using user-supplied embedded images. * Have each such autogenerated file also define a special symbol, along the lines of ''obj_XXX''; maybe ''firmware_XXX'' where ''XXX'' is some identifier-ized version of the firmware filename. * Provide a function, ''get_firmware()'', that can be called by a driver needing a firmware blob. If the blob exists (matching on filename) as a loaded image, it is unregistered from the image table, its image structure is freed keeping its data, and the ''userptr_t'' to the data is returned to the requesting driver. If the blob is not found, an error is returned. * Provide a macro, ''REQUIRE_FIRMWARE()'', that works like ''REQUIRE_OBJECT()'' to pull the specified firmware file into the link by introducing a dependency on the ''firmware_XXX'' symbol. If the required firmware is not available, the link will fail. This would be used for drivers with freely distributable firmwares included with gPXE. * Provide a macro, ''USE_FIRMWARE()'', to note a dependency on a certain firmware file without forcing it to be present for the link to succeed. There may be a way to use the linker for this, or it could define a symbol visible with ''nm'' and a script could add dependencies on those ''firmware_XXX'' symbols both requested and available. This would be used for drivers for which obtaining firmware requires jumping through some hoops (e.g. b43). * //Update 7/3//: After trawling linker documentation, I've found that the desired behavior can be effected using ''REQUIRE_FIRMWARE()'' plus a linker script that does ''PROVIDE(firmware_XXX = 0);'' for each firmware symbol that should not cause a link error if it is not present, but should still pull the firmware into the link if it is available. The easiest way to manage this is probably to require that each driver requiring non-included firmware place a linker script in ''fw/'' with the ''PROVIDE()'' commands in it, and include all of those scripts in the link. * Main wireless stack things: * WPA-Enterprise support //might// be useful. * Not-quite-wireless things: * We need a proper cryptographic RNG. I could look into using the Yarrow algorithm or a similar one, with as much real entropy as we can get from low-order bits of the TSC during timer interrupts. ==== Friday, 3 July ==== WPA2 is working.
