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:journal:week6 [2009/07/03 15:56] rwcr |
soc:2009:oremanj:journal:week6 [2009/07/10 14:06] (current) rwcr |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ====== Joshua Oreman: 802.11 wireless development ====== | ====== Joshua Oreman: 802.11 wireless development ====== | ||
| - | ===== Journal Week 5 ===== | + | ===== Journal Week 6 ===== |
| ==== Monday, 29 June ==== | ==== Monday, 29 June ==== | ||
| Line 80: | Line 80: | ||
| * 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, ''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). | * 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. 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. | + | * //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: | * Main wireless stack things: | ||
| * WPA-Enterprise support //might// be useful. | * WPA-Enterprise support //might// be useful. | ||
| Line 86: | Line 86: | ||
| * 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. | * 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! | ||
| + | * [[http://git.etherboot.org/?p=people/oremanj/gpxe.git;a=commit;h=fc7d95d70fd197319dc4f0138ba2df3705286e91| | ||
| + | [crypto] Make AES context size and algorithm structure externally available]] | ||
| + | * [[http://git.etherboot.org/?p=people/oremanj/gpxe.git;a=commit;h=436b6980765eb7bb5061a8fd301affe9af0f8283| | ||
| + | [crypto] Add AES key-wrap mode (RFC 3394)]] | ||
| + | * [[http://git.etherboot.org/?p=people/oremanj/gpxe.git;a=commit;h=b9025f9a595fd44e86b0957f12db4381de801010| | ||
| + | [wpa] Remove KIE encrypt function, and allow decrypt to return an error]] | ||
| + | * [[http://git.etherboot.org/?p=people/oremanj/gpxe.git;a=commit;h=8f4e89b9e81bc2a3b714d7a49de1efd18c86e904| | ||
| + | [tkip] Make private functions static]] | ||
| + | * [[http://git.etherboot.org/?p=people/oremanj/gpxe.git;a=commit;h=fdaaa4d9df9e43ce825d9b37e11126c9f36a7f31| | ||
| + | [wpa] Avoid recomputing Snonce during handshake + some minor tightening]] | ||
| + | * [[http://git.etherboot.org/?p=people/oremanj/gpxe.git;a=commit;h=be6d51f8d83f42717d580b6df0057886b2f4119f| | ||
| + | [wpa] Add support for CCMP encryption (AES-based, WPA2 default)]] | ||
| + | |||
| + | I was able to connect to a network that uses CCMP for unicast packets and TKIP for broadcast packets, and do DHCP (which uses broadcast) and chainload tomsrtbt (unicast) without any crypto errors. (The unicast/broadcast cipher split is fairly common, because the broadcast cipher has to be supported by every node, while a unicast cipher can be negotiated with each node separately.) | ||
| + | |||
| + | Before that, I discovered that writing a memory-processing loop like this: | ||
| + | for ( i = nblk; i >= 1; i++ ) { | ||
| + | /* ... */ | ||
| + | } | ||
| + | is a surefire road to a hair-pulling two-hour debugging session. Learn from my mistake, and don't write descending loops as ascending loops. :-) | ||
| + | |||
| + | CCMP uses AES in two ways: in key-wrap mode (RFC 3394) to protect the group key in the 4-Way Handshake frames, and in counter mode with CBC-MAC (CCM; RFC 3610) to handle normal data packets. I implemented AES-wrap as a generic crypto function, since it is reasonably simple and does not have many tunable parameters; it doesn't have a ''crypto_algorithm'' structure, but that's just a matter of it being almost uniformly used for bite-sized chunks of data that are generally operated on in one piece. For CCM, I made the implementation private to WPA2 because that allowed me to make WPA2-specific size-saving assumptions about how it would be used. I kept the encryption and MACing code separate from the packet marshalling code, though, so if another use for CCM arises it should be fairly easily genericizable. | ||
| + | |||
| + | This will be my last coding work until July 20. In the meantime I will be preparing for and competing in the [[http://ipho2009.smf.mx/home|2009 International Physics Olympiad]] in Merida, Mexico. Wish me luck! :-) | ||
| + | |||
| + | After I get back: drivers drivers drivers... | ||
