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/13 11:44] 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 95: | Line 95: | ||
| Meeting minutes: | 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. | * 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 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. | * Need to allow imgfree with an argument, at least in cases (scripts) where this can be safely done. | ||
| Line 103: | Line 104: | ||
| Priorities for this coming week: debugging cleanup, mainline cleanup, iSCSI testing, rate control. | 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. | 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. | ||
