n2k15: stsp@ on 11n mode wifi, testing

Fresh from the recently completed n2k15 hackathon, here comes Stefan Sperling's (stsp@) report:

I spent most of my time at n2k15 preparing and testing fixes for initial 802.11n support for OpenBSD.

The current goal of this project is to support mandatory 802.11n features:

Send and receive using data rates MCS 0-7. In terms of throughput these are essentially equivalent to 802.11a/g except for MCS 7 which sends up to 65 Mbit/s.

Support receiving two kinds of aggregated frames: A-MPDU and A-MSDU. Frame aggregation avoids overhead involved in sending a separate ACK for each frame. The medium is reserved for a longer time than usual and several frames are transmitted back to back. The receiver sends a special Block Ack frame indicating which frames were received successfully (A-MPDU) or a single Ack frame for the entire aggregate (A-MSDU).

Support for frame aggregation is required by the 802.11n standard, at least when receiving frames. Technically, sending is required, too, but in practice no AP really cares if we don't send such frames so I'm treating the send operation as an optional feature.

Note that the killer features of 802.11n are all optional. What's being built at the moment is a solid foundation for future work. Any perceived improvement in throughput is just a side effect of adding this foundation. The real performance improvements will happen later.

Most the my net80211 layer changes had already been committed before n2k15, except for my frame aggregation support patches which still lacked proper testing. Lack of testing means uncertainty about what happens on various valid and invalid inputs, which in the worst case might crash the kernel. So I really needed something to verify our code against.

The decision to send aggregates is implementation-defined, and I had no access points which sends A-MSDUs (at least, that's what I believed at the time). Finding equipment to test wifi under controlled conditions is pretty hard if all you can get is hardware sold to regular consumers.

A web search for "A-MSDU" showed that even Linux and FreeBSD developers have had this problem, some years ago already, and were sharing tips about which specific APs or device firmware were well suited for generating A-MSDUs. But there was not enough information for me to go out and buy a specific product in a store today. And it seemed there was not even a single in-tree open source driver sending A-MSDUs, for neither Linux nor FreeBSD!

My search eventually surfaced patches sent to the linux-wireless mailing list by a Linux developer working at Intel. These patches implemented A-MSDU transmit for the open source Linux iwlwifi driver, and were just about 4 weeks old. After wasting some time trying to get these patches applied to the official Linux tree, I contacted the developer who pointed me at a git repository maintained by Intel's developers where he had committed his patches just 4 days earlier. Good timing!

Getting Linux to run with these patches on my APU board took most of my time during n2k15. I needed a bleeding edge kernel to compile against and the necessary tooling to run an access point. I first tried OpenWRT's latest development tree but their kernel was too old and patching around that was too difficult. I ended up installing Debian's testing distribution and got the driver to compile and run there.

Asking for help with installing Linux in a room full of OpenBSD hackers is an exercise in futility. Nobody showed much interest except when I came across funny bits like Debian's installer asking whether I wanted to install the system in the English language or in the C language. Eventually, mikeb@ got tired of my expletives and helped me fix the grub2 boot loader setup so my freshly installed Linux system would actually boot and also show output on the serial console.

The next hurdle turned out to be that this AP didn't actually recognize OpenBSD clients as capable of 802.11n. I poked at this problem a bit but this was already my final day at n2k15 so I had to leave it at that.

Once I got back home I continued investigating. It turns out we need to send a special vendor (Microsoft) specific element in association requests to indicate QoS support to a Linux AP?!? The official mechanism defined in the final 802.11n standard is different and apparently not implemented everywhere. Both Linux and FreeBSD send this element by default and now OpenBSD does, too. The Linux AP now treated OpenBSD as an 802.11n client and started sending A-MSDUs so I could finally test OpenBSD's A-MSDU code.

I discovered a bug in the A-MSDU transmit code in iwlwifi where it sent bad frames if hardware encryption was performed on A-MSDUs. I reported this back to the Linux developers so this corporation turned out to be beneficial for both projects! (http://marc.info/?l=linux-wireless&m=145009697608343&w=2)

One of my APs at home now started throwing A-MSDUs at OpenBSD, too. It is Linux based but locked down such that there is no easy way of compiling a custom firmware to run on it for testing. Having had no way of looking into its operation at the required level of detail I never realized there had been a problem.

Many thanks to reyk@ and his team for organising the event, and to all who shared mulled wine and songs on Saturday evening, and to those who tolerated the resulting noise in the hackroom.

Thanks for the report, Stefan! Some of us are already enjoying this code in practical use.