I get plenty of emails asking questions about tweaking 802.11 stack in Linux.
Having spent a lot of time working and understanding it in the hope for a publication, but unfortunately I didn’t get a deployment on actual machines so that I can get some data and analyse it. I wish I could have written something about modification to Qualcomm’s firmware as I modified it in my internship, but I can’t talk about it due to proprietary reasons.
Most of my understanding has been developed by reverse-engineering hardware registers and driver codebase. I am glad Atheros has made the code opensource that can be tweaked. Adrian Chadd(Free BSD developer) and Felix Fietkau(OpenWrt) have given valuable inputs and so have some unknown IRC hackers(including Daniel Smith) who have been wonderful suggesting ideas in while I tried modifications in the the darkest of nights :-).
In this post I shall discuss some important things about 802.11 and provide a kernel patch for it. I have also included a python library(like tcpdump) which can parse the modifications made to packet headers.
Linux wireless stack currently doesn’t provide a lot of information of the 802.11 PHY layer from the hardware because of lack of standardization of many flags and fields in the radiotap header to make it available. It’s also true that different wireless chipsets don’t provide the same level of granularity/information one needs and these are hard to address for mac80211 kernel API.
802.11 a/b/g/n ath9k driver codebase is massive compared to the older ath5k and MadWifi drivers and can be a pain to work with! I have appended fields in radiotap header to keep it compatible with tools like Wireshark and tcpdump to get per frame information than opening a /proc interface which will be significant overhead to read on an embedded device if one has to sample at per packet granularity.
There is plenty of information that 802.11 driver keeps with it but is not exposed in userland. They are vital and can be used in detecting a lot of problems that your wireless stack network might be facing and you are unaware of it.
For example, hardware frame transmission timestamps from a device are not provided in userland, although this information is present in the driver. Current timestamps provided by tools like tcpdump and Wireshark are the ones provided by the network adapter rather than by the hardware device. Hence, they should not be trusted at microsecond granularity and also not be compared with timestamps provided by radiotap headers for the received frames. There are additional points to consider when looking at hardware timestamps. 802.11 n transmits AMPDU and the hardware returns a callback only when the transmission is complete for the whole AMPDU. So one must understand it is obvious that he might see same timestamp for more than one frame, and has to check a related flag in the radiotap to check that condition has occurred!
One of the PHY layer information that might help in detecting microwaves and other Non-Wifi interfering devices are CCK and OFDM error counters maintained by ANI system in driver. Their frequency increases in the presence of such devices as the hardware fails to decode the frames at the PHY layer. There are other errors which when turned on might increase the work (DMAe’d by device to the main memory) might cause a degradation in the performance of the router, so use them at caution or use oprofile to profile the performance at high workloads. I have primarily worked with ARM based processor- embedded systems, but if you are using x86 machine, then you don’t have to worry about it.
If one wants to know which bitrates were tried, the order in which they were tried and the number of retransmissions experienced by each, that information is also appended to the modified radiotap header.
I have also written a complete parser similar to Wireshark/tcpdump for parsing the additional fields appended to the radiotap headers.
I would be happy if someone can actually collect real data using such patch which can help to understand wireless networks better!
I have done some very basic data collection, results of which can read by building my PhD presentation, which was also presented at IS4CWN 2013.