Contributed by pitrh on from the sunshine and krautwerk dept.
This hackathon I took time to kick off a project I have been wanting to try for some time but never got around to: Adding sound support for my laptop which uses an internal USB audio device wired to xhci(4). Our xhci(4) driver lacks support for data transfers with guaranteed bandwidth and timing constraints (aka isochronous transfers). The first step is to add support for such transfers (mpi@ tells me the rabbit hole ends up in uaudio(4) but I'll worry about that later). To get started, I spent some time reading parts of the USB 2.0 and USB 3.1 specs, as well Intel's data sheet for the xHC interface (linked from https://en.wikipedia.org/wiki/XHCI). Equipped with this new knowledge, I started brushing up an old work-in-progress diff that mpi@ shared with me. I did not make much progress and eventually got side-tracked into the wireless stack. But having finally explored this problem space feels good! I will try to keep exploring.
Back in wireless land I improved support for access points with disabled 802.11b support to prevent old and slow devices from hogging air time, at the expense of backwards compatibility. Many of our drivers hard-code 11b rates into the hardware when sending broadcast frames, so they won't work in such networks. The iwn(4) and iwm(4) drivers now respect the basic rate set announced by the access point in its beacon and won't send broadcasts on rates not included in this set. The iwm(4) parts of this were implemented by phessler@ (thanks!). Many drivers still need to be looked at and fixed, but changes required in each driver are small. If anyone would like to help with this, please talk to me.
I also fixed a bug in iwm(4) which caused fatal firmware errors when the interface was reconfigured several times in quick succession.
Meanwhile, krw@ and mpi@ improved dhclient's link detection logic, and this exposed an old link state reporting bug in the net80211 layer. The link state of a wireless interface was in the UNKNOWN state the first time the interface came up after boot. The UNKNOWN state caused dhclient to assume the interface was UP and to start sending DHCP request packets into the void instead of printing its '....sleeping' message.
Once the interface had successfully associated once, and was brought down again, the net80211 layer set the link state from UP to DOWN and dhclient would behave normally from here on.
The fix was simple: Always set the interface link state to DOWN before configuring the interface, regardless of whether the interface was previously associated with an access point.
Towards the end of the hackathon I added another regularly requested feature: iwn(4) and iwm(4) interfaces now notice when an access point grows legs and walks out of range. To detect this, the drivers listen to 'missed beacon' events signalled by the hardware. Once a certain number of consecutive beacons were missed, the driver sends a probe request to the access point. If the access point answers with a probe response the interface stays connected. If no response from the access point is received, the act of sending a probe request triggers a useful side effect: The net80211 layer automatically puts the interface into SCAN state, which initiates a search for a new access point.
Overall, this was a great (and sunny!) hackathon. Great veggie food and the occasional dive into Starnberg's crystal-clear lake made for a very nice experience. Thank you mpf@ for organizing the event, and to genua gmbh for sponsoring the event.
Thanks for the report, Stefan!
We've also included a picture Stefan included with the story, it sure looks like a nice part of Germany, that!
(Comments are closed)