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:week2 [2009/06/01 21:12] rwcr |
soc:2009:oremanj:journal:week2 [2009/06/07 23:54] (current) rwcr |
||
|---|---|---|---|
| Line 30: | Line 30: | ||
| The Linux driver shared some code with a driver supporting rtl8187 - that's the "rtl818x" that shows up some places. I'll port over the rtl8187 driver if I get some hardware that uses the chipset. | The Linux driver shared some code with a driver supporting rtl8187 - that's the "rtl818x" that shows up some places. I'll port over the rtl8187 driver if I get some hardware that uses the chipset. | ||
| + | |||
| + | ==== Thursday, 4 June ==== | ||
| + | Made some pretty good progress on coding the MAC layer: | ||
| + | * [[http://git.etherboot.org/?p=people/oremanj/gpxe.git;a=commit;h=8d60d36fe400799acfd74b8f8988b5dc5a3cd4e9| | ||
| + | [netdevice] Add netdev argument to ll_protocol::push, pull]] | ||
| + | * [[http://git.etherboot.org/?p=people/oremanj/gpxe.git;a=commit;h=ab39548abf5261b240c97ac62df317172fd7254a| | ||
| + | [802.11] The 802.11 MAC layer, first big commit]] | ||
| + | So far I've implemented the basic structure of everything (including a framework to fill in for crypto), link-layer encapsulation, net_device wrapping, and rx defragmentation. I still need to handle received management frames, especially those involved in associating with a network, and write said association code. The beacons received during association also need to be used to construct the lists of channels and rates on which the device can communicate, and those lists need to be freed at the appropriate time. | ||
| + | |||
| + | gPXE with the rtl8180 driver now builds cleanly, because I've stubbed the necessary 802.11 functions that haven't been implemented. If you run it it will probably time out waiting for "link-up" (which is how I've chosen to represent association to the network stack) because there's nothing going on to get the association in place. | ||
| + | |||
| + | Tomorrow I work on management frame parsing, and maybe get to test all this stuff. | ||
| + | |||
| + | ==== Friday, 5 June ==== | ||
| + | |||
| + | |||
| + | |||
| + | More work on the MAC layer, to fill in the gaping "insert association functionality here" hole. No commits today, since I got to a state where the code had a dozen half-finished parts and I should be able to clean it up tomorrow. I realized I hadn't fully mapped out how the association process should work, so I took a break from the coding to do that; the notes are in my [[soc:2009:oremanj:notes:design|design notes]] page. I figure the association will be managed by a process that's created whenever it's needed. My goal is to have it appear to higher layers like the "link up" on a wired Ethernet link, so it needs to happen asynchronously - netdev_open() returns right away, and some time later the ''NETDEV_LINK_UP'' flag is automagically set (assuming everything works properly). | ||
| + | |||
| + | The association process will be able to be invoked by an "auto-association" method, which takes parameters from gPXE settings and is used on initial device open, and a "associate to specified" method for command-line use. The auto-associate method can just call associate-to-specified with appropriate parameters, so there's no code bloat introduced by having both, and the latter will be useful for debugging. Either of those methods starts the association process, which handles the four steps of 802.11 association in turn: set up parameters, send authentication, send association, cryptographic handshaking. The ''net80211_device'' will include a ''state'' field to report information about which parts of this have been done, so e.g. if we receive a disassociation packet from the AP we know we only need to redo the last two steps. | ||
| + | |||
| + | Weekly meeting tomorrow. | ||
| + | |||
| + | ==== Saturday, 6 June ==== | ||
| + | (I'm working Saturday and Sunday this week because I missed Tuesday and Wednesday.) | ||
| + | |||
| + | Notes from weekly meeting: | ||
| + | * Association should be triggered via a settings applicator, on netX/ssid. That setting can be handled as a netX-scoped ''struct setting''. mcb30 gave a great explanation of how the settings system works. | ||
| + | * Code review of [[http://git.etherboot.org/?p=people/oremanj/gpxe.git;a=commit;h=8d60d36fe400799acfd74b8f8988b5dc5a3cd4e9|8d60d...]]: The netdev argument to push/pull needs "Network device" instead of "Network device pointer" in its doxygen comments. | ||
| + | * Coding style issues: spaces around parentheses in non-driver code, proper Doxygen-style comments on things (row of stars down the second column) and use of ''@v'' and ''@ret'' lines for function documentation. | ||
| + | * Datasheet question: it'd be a good idea to email the authors of the rtl8180 drivers for Linux and/or FreeBSD and ask if they've got a sheet. | ||
| + | * Milestone for next week: get the MAC layer usable by Wednesday, spend remainder of time testing and bugfixing rtl8180 boot, hopefully have working boot by end of week. | ||
| + | * Hardware purchase issues: [[http://www.amazon.com/RTL8185L-802-11g-Wireless-LAN-Adapter/dp/B0012430RS/ref=sr_1_20?ie=UTF8&s=electronics&qid=1244312934&sr=1-202009-06-06|we found a rtl8185 card]] | ||
| + | |||
| + | Commits for today: | ||
| + | * [[http://git.etherboot.org/?p=people/oremanj/gpxe.git;a=commit;h=490714353c660e66b84953444fe48f282f515019| | ||
| + | [802.11] The 802.11 MAC layer, second big commit]] | ||
| + | * [[http://git.etherboot.org/?p=people/oremanj/gpxe.git;a=commit;h=bae2489240d2eecd28a3f54bb3de3287a4aadf28| | ||
| + | [drivers rtl8180] Updated rtl8180 driver for API changes]] | ||
| + | * [[http://git.etherboot.org/?p=people/oremanj/gpxe.git;a=commit;h=095b23f38626677c11781ae9a0fedc29fde40d5d| | ||
| + | [aesthetic] Adjust parenthesis spacing on net80211.[ch] to fit gPXE style]] | ||
| + | |||
| + | I'm almost done with the initial coding for the MAC layer; all I have left to write is the network scanning function, ''net80211_probe()''. It looks like I should be able to start testing bug-hunting on Monday if not tomorrow. | ||
| + | |||
| + | I did some packet sniffing on my home wireless network today, and found that ordinary 2.4GHz-band consumer-grade networks generally don't even include the IEEE country information element that I had assumed we'd be able to use to set regulatory parameters. It may be possible to get at them with a probe packet, but if not, we're left guessing about maximum TX power - we'd have to use 20 dBm (maximum value for Europe and Japan) even in the US where a higher-range 27 dBm is allowable. For now I'm leaving it fixed at 20 always. | ||
| + | |||
| + | ==== Sunday, 7 June ==== | ||
| + | Finished the initial required MAC layer functionality, and started testing on hardware. Commits: | ||
| + | * [[http://git.etherboot.org/?p=people/oremanj/gpxe.git;a=commit;h=37f14d3d7185ce246b80b445e5909fe07ba01453| | ||
| + | [802.11] Fix sequence number fields in ieee80211.h]] | ||
| + | * [[http://git.etherboot.org/?p=people/oremanj/gpxe.git;a=commit;h=008a668a4ab75af0373bc3068ecb7102945851ff| | ||
| + | [802.11] MAC layer: Add probe functionality, other small improvements]] | ||
| + | * [[http://git.etherboot.org/?p=people/oremanj/gpxe.git;a=commit;h=0bf3c5b8d63e89da3ff4d75fb7665373ded7db99| | ||
| + | [drivers rtl8180] Fix a couple bugs, add a bunch of debugging]] | ||
| + | |||
| + | If we want to support site survey ("show me a list of networks"), most of the code in net80211_probe() can be factored out into a separate function that's called from either probe() or scan(). For now I've left scan() unimplemented. | ||
| + | |||
| + | I doubt net80211.c is going to be getting much bigger; most of the remaining code bulk will be in encryption, which I plan on making separable from the main MAC layer (so you can just compile in the encryption methods you use). Currently the code size for 802.11 is 5.8k, which IMO is not so bad. | ||
| + | |||
| + | With a couple obvious bugfixes, the rtl8180 card initializes and starts receiving packets. The first serious problem I ran into involves receiving packets of at least 85 bytes (maybe lower, but more than 64): the card signals a DMA error. Everything is aligned more than required (to 1k where the card needs 256b), all DMA is using physical addresses, the rx buffer size is set to 2356, I dunno what could be going wrong. Tomorrow I'll scrutinize my changes from the Linux driver and make sure I didn't inadvertently introduce something stupid. | ||
| + | |||
| + | It does receive a great many probe request packets from my TiVo just fine, which I think is a small victory. :-) | ||
| + | |||
