Contributed by phessler on from the al the bits that want to fly dept.
Because this network hackathon was scheduled very close to the 6.0 release I focused my efforts on fixing bugs.
The first bug I encountered was that dhclient no longer works if DHCP return traffic has to pass through a bridge, and the member interface which receives the DHCP return traffic also has a dhclient instance running on it:
DHCP server laptop APU board attached to laptop (fxp0) ---------- (em0-bridge0-em1) ------- (ix0) ^ dhclient em0 ^ dhclient ix0 gets no replies
In this case, the dhclient instance which runs on the bridge member interface accepts DHCP replies destined to the other dhclient and drops the packet. Before some recent surgery in the network stack, the packet was first passed into the bridge and then dropped, which is why this setup used to work fine.
In the wireless stack, I fixed an old bug in the iwm(4) driver which prevented RTS frame protection from being used for frames above a certain size.
Briefly explained, RTS protection avoids data frame collisions by sending a special "Request-To-Send"' frame to all wireless devices on the channel, which essentially says:
"I am going to transmit the next data frame, and I will require N msec of time to do so, now everyone else please stay quiet until I'm done."
The RTS mechanism (or, more generally, RTS/CTS) reduces chances of interference due to direct competition for the medium. Direct competition works very well in Ethernet but works less well for radio networks because of the hidden node problem. RTS/CTS helps especially in cases where older wireless devices, which do not understand frame formats introduced in newer standards, are present. An access point may advise everyone to use RTS protection by setting a flag in its beacon, e.g. an 11g AP might set this flag if an 11b device shows up. Additionally, any device may independently decide to use RTS for any reason. A common client-side heuristic is to use RTS for frames which exceed a particular size because larger frames are more likely to get damaged by interference since they take more time to transmit.
Later on, I realized the above fix was useless in isolation, since our wireless stack had been setting the RTS threshold to the maximum frame size since 2004. This was in response to phessler@ reporting the wireless network in our hack room was so unusable for him he could not even copy kernels between laptops. After looking over packet traces which showed that each frame was being retried up to about 10 times, we forced RTS on and packets started flowing smoothly. Similar fixes related to RTS went into the rtwn(4) and urtwn(4) drivers.
I also repaired the ural(4) driver which was broken according to a report by martijn@. A typo introduced sometime in November last year caused a check in the transmit logic to flip around, so the driver was programmed to not send any frames while the device was up, and send frames only while the device was down... Obviously, that won't work.
Also on my list was enabling HT protection for iwn(4) in 11n mode. The HT protection setting determines whether 11n devices will use RTS and/or whether they will use frame formats which older devices can understand. The current setting is advertised by the AP and may change at any time as non-11n devices show up and disappear. It is important to keep track of changes to this setting while associated. The code I had written for iwn(4) to update the current setting had a bug which broke frame transmission on some devices. Both mlarkin@ and krw@ saw the bug on a particular hardware model supported by iwn(4). I bought one of these devices and brought it to Prague, where I managed to track down the bug.
For some reason, HT protection updates were also broken in iwm(4), even though I'm quite sure I had them already working at some point.
Many, many thanks to sashan@ and Mr. Decky from CUNI for organizing this awesome event for us. I had a ton of fun. It was also very nice occasion to put some new faces to names (e.g. Richard Procter, who traveled all the way to Prague from New Zealand).
And shout outs to Larry Ellison for (inadvertently?) covering our not quite insignificant beer tab (let's just say that, by the end of that night, the bar had run out).
Thanks for the report and the work, Stefan! We look forward to seeing the results in the upcoming release (and snapshots).
(Comments are closed)