This is an old revision of the document!
====== Joshua Oreman: 802.11 wireless development ====== ===== Journal Week 3 ===== ==== 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 size of gpxe.lkrn 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...''
