OpenBSD Journal

n2k16 hackathon report: Stefan Sperling on dhclient bugs, iwm(4) issues

Contributed by phessler on from the al the bits that want to fly dept.

The first report from the just-concluded n2k16 hackathon comes from Stefan Sperling, who writes:

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.

I suggested a fix and krw@ implemented it. However, the fix I suggested caused a regression reported by Holger Mikolon, so I had to revert the change to avoid swapping one problem for another in 6.0.

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)

  1. By Billy Larlad ( on

    Thanks for taking the time to write up such a lengthy report. These kinds of things always make for interesting reading.

    Also, it's always good to read of new faces showing up at hackathons. It's good news that the project is always attracting bright new minds!

  2. By kaliszad ( on

    Unfortunately, I couldn't come to Prague. What was the beer reference by Larry? Do your mean the 22nd of July Heineken advert on @Oracle Twitter account?

    1. By Anonymous Coward ( on

      > What was the beer reference by Larry? Do you mean the 22nd of July Heineken advert on @Oracle Twitter account?

      Ir's clearly a joke. Oracle sponsored this network hackathon, likely due to the fact that they're incorporating OpenBSD pf and helping with SMP development.

      > Unfortunately, I couldn't come to Prague.

      Hackathons are invite-only AFAIK..

  3. By kaliszad ( on

    Oracle wouldn't sponsor a pub visit, would they?

    1. By sashan@ ( on

      > Oracle wouldn't sponsor a pub visit, would they?
      tehcnically speaking: it was not 'pub visit', but 'yacht club' visit.
      the admission for non-members is quite high, but as soon as you get
      in, the drinks are for free.

  4. By gtz (2001:4c50:fffa:b2cd:89e7:5249:bc18:d261) on

    I always thought that we where supposed to create a vether(4) interface, add it to the bridge as a member and than configure the IP-adresses on the vether(4) interface instead of the physical member interfaces?

    At last that's what I do and it seams to work fine.

    1. By Chris Cappuccio ( on

      > I always thought that we where supposed to create a vether(4) interface, add it to the bridge as a member and than configure the IP-adresses on the vether(4) interface instead of the physical member interfaces?
      > At last that's what I do and it seams to work fine.

      It works if you configure any bridged interface, too. Your method totally side steps the issue


Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]