✎ soc:2009:oremanj:journal:week4

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Joshua Oreman: 802.11 wireless development ======

===== Journal Week 4 =====

==== Monday, 15 June ====
Worked on a bunch of small things today. My video card didn't come until late in the day, so I was only able to do a little iSCSI testing, but what I found was revealing.

Commits:
  * On branch **mainline-review**:
    * [[http://git.etherboot.org/?p=people/oremanj/gpxe.git;a=commit;h=18e6470d06d8846d531d97d881be6f1278bd2f15|
[nvs] Add init function for Atmel 93C66 EEPROM]] [+0 bytes]
    * [[http://git.etherboot.org/?p=people/oremanj/gpxe.git;a=commit;h=d429b31ac28760004e753dc79178400d507975e2|
[netdevice] Add netdev argument to link-layer push and pull handlers]] [-12 bytes!]
    * [[http://git.etherboot.org/?p=people/oremanj/gpxe.git;a=commit;h=f77b486f42b2b12604ce94d65cbba33b55a589e5|
[netdevice] Adjust maximum link-layer header length for 802.11]] [+0 bytes]
  * On branch **wireless**:
    * [[http://git.etherboot.org/?p=people/oremanj/gpxe.git;a=commit;h=37f97824d5ac03f8af16afab61d473c99b3ace7c|
[802.11] Debug and output cleanup, minor association improvements]]
    * [[http://git.etherboot.org/?p=people/oremanj/gpxe.git;a=commit;h=08cfc42994e6f35dc8b0796d863861678f835470|
[netdevice] Add print_status callback for link-layer-specific state]]
    * [[http://git.etherboot.org/?p=people/oremanj/gpxe.git;a=commit;h=66f79b57a1ea0354b8339fc508c655f2d46d0ec9|
[Makefile] Remove -Wformat-nonliteral command-line option]]
    * [[http://git.etherboot.org/?p=people/oremanj/gpxe.git;a=commit;h=e418cc6fab843f4831d8f016f75cf6813be4b166|
[802.11] Clean up channel and rate handling]]

I have no idea how adding a function argument managed to //decrease// code size, but it did. (Measuring uncompressed text size of gpxe.lkrn.tmp with no debugging.)

So far the changes on mainline-review are all the commits I made before yesterday that are not in my rtl8180 driver or in 802.11-specific code. I want to get a few things sorted out with 802.11 handling before I push it into mainline review - specifically some kind of rate handling, as working at 1 Mbps is a little undesirable :-)

Questions I'd like to get answered by someone with the authority to decide such things:
  * Is my ''print_status()'' addition consistent with the gPXE Way? I think having the 802.11 state is important - if a user says "it's really slow" the first thing we'd ask is an ifstat to show signal strength and transmission speed. An alternative would be to special-case 802.11 in the ''ifstat()'' code using ''net80211_get()''; if we did that, we could only avoid always linking in 802.11 support by using linker tricks like weak symbols.
  * Is removing -Wformat-nonliteral an acceptable tradeoff for 60 bytes of uncompressed code size?
  * How asynchronous should association be? Currently the probe part is synchronous (freezes gPXE for a few seconds) and the rest is asynchronous. I think we should probably push it all in one direction or the other. A blocking association with a status message would have the advantage of obvious error reporting (user doesn't have to check ifstat to see it failed and compile with ''DEBUG=net80211'' to see why), and of preventing the possibility of over-eager networking code sending packets before the link is up, but it detracts somewhat from the "it works just like a wired link with respect to link-up" abstraction.

iSCSI testing using DOS scandisk produced a complete scan with no errors, but one significantly slower than wired and quite jagged in its progress. (The unit of progress, 16 clusters, took anywhere between 3 seconds and a minute.) I did this testing before I fixed a bug in the rate-choosing code; what was supposed to be a "conservative" choice of the first 802.11b rate (1Mbps) actually had its logic inverted to use the first 802.11g rate, which in this case was 18Mbps. My host-AP and test machines are about a meter apart, which 802.11 RF modulation is not designed for, so I expect there was a great deal of packet loss between the two. The periodic stalling suggests some TCP strangeness that's borne out by the packet captures. I don't know enough about TCP to diagnose this, but I've posted the packet captures for posterity anyway. 
Both represent a scan of about 500 clusters on the same disk.
  * [[http://etherboot.org/share/oremanj/iSCSI-test-wired.cap.gz|gzipped wired capture file (3.8MB)]]
  * [[http://etherboot.org/share/oremanj/iSCSI-test-wireless.cap.gz|gzipped wireless capture file (2.7MB)]]

**Update:** Testing at 1Mbps produced even more horrible results, with upwards of 43 duplicate ACKs detected from my computer to gPXE for the same segment. For almost every single TCP segment. I think this may be an issue with capturing on the same node that's hosting the Access Point; I'll test more with the WRT54G when I receive it tomorrow.

==== Tuesday, 16 June ====
  * On branch **mainline-review**:
    * [[http://git.etherboot.org/?p=people/oremanj/gpxe.git;a=commit;h=a9a0567225493046f70e6252e21ab5c6d8219e87|
[image] Modify imgfree command to accept an argument]] [+88 bytes]

''to be continued...''
Trace: • week11 • week5 • 2009 • week5 • week3 • week9 • week7 • week8 • week4 • week1 • week9 • week4 • week3
Navigation

Search

Toolbox

QR Code
