====== 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:week3 [2009/06/12 23:47] rwcr |
soc:2009:oremanj:journal:week3 [2009/06/15 14:50] (current) rwcr |
||
---|---|---|---|
Line 26: | Line 26: | ||
Things left to do on 802.11 include: | Things left to do on 802.11 include: | ||
* <del>[easy] Provide CTS protection if the network asks for it; required for 802.11 g/b interoperability.</del> Done 6/12 | * <del>[easy] Provide CTS protection if the network asks for it; required for 802.11 g/b interoperability.</del> Done 6/12 | ||
- | * [easy] If we don't get a response to our assoc/auth packets within a few seconds during the association phase, resend them. | + | * <del>[easy] If we don't get a response to our assoc/auth packets within a few seconds during the association phase, resend them.</del> Done 6/15 |
- | * [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. | + | * <del>[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.</del> Decided 6/15 not to do; it would cause network probe to use significantly more resources, without benefiting the typical gPXE user. The minimal automatic functionality we have now (associate with strongest-signal if SSID is blank) should be enough. |
- | * [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] 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.) <del>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).</del> |
* <del>[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.</del> Error encoding done 6/12 | * <del>[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.</del> Error encoding done 6/12 | ||
* [easy, added 6/12] Clean up status displays, so the prompt doesn't appear in the middle of the association message after an ifopen or SSID set. | * [easy, added 6/12] Clean up status displays, so the prompt doesn't appear in the middle of the association message after an ifopen or SSID set. | ||
Line 90: | Line 90: | ||
I've also started thinking about how to handle encryption elegantly; I'll post a description here once I run it past the mentors in our meeting tomorrow. | I've also started thinking about how to handle encryption elegantly; I'll post a description here once I run it past the mentors in our meeting tomorrow. | ||
+ | |||
+ | ==== Saturday, 13 June ==== | ||
+ | |||
+ | Meeting minutes: | ||
+ | * Michael couldn't make it to most of the meeting, but he sent an email prior. I need to start preparing my changes to be merged into mainline, using a separate branch with properly-separated commits. Debugging messages should be done using the gPXE standard DBGC, and the "[802.11 associating... ok, <network>]" message should not be enabled by non-debugging default. | ||
+ | * All the items from last week's meeting have been addressed. | ||
+ | * Need to send an email to etherboot-developers about the image strangeness observed yesterday. | ||
+ | * Need to allow imgfree with an argument, at least in cases (scripts) where this can be safely done. | ||
+ | * Noted that the best places to start for 802.11 knowledge are the Linux code (in net/mac80211/) and the 802.11 spec from IEEE (see my notes page). | ||
+ | * Discussed possible handling of required firmware files for b43 and similar cards: use an embedded image and document distribution restrictions. | ||
+ | * Need to do some performance testing. | ||
+ | * Marty had some iSCSI issues in testing. iSCSI wouldn't autoboot - this seems to be down to the timing and asynchronous nature of association - and when manually booted a "scandisk" call eventually seemed to stall. I'll test this on my own setup where I can sniff the wire, and see what's happening with the scandisk problem. | ||
+ | |||
+ | Priorities for this coming week: debugging cleanup, mainline cleanup, iSCSI testing, rate control. | ||
+ | |||
+ | I think it might be a very good idea to change association to run synchronously, using the monojob interface. I've already seen a few issues that were caused by the asynchronous process being interleaved with some activity that should strictly follow it. Need to get Michael's input on this. | ||
+ | |||
+ | I'll have a video card arriving on Monday, so I can update my kernel and use the host-AP and packet injection functionality of my card. | ||
+ | |||
+ | Also, Marty was kind enough to send me a WRT54GL :-) so I should be able to get more testing done with that. | ||
+ |