I've been doing some reading and testing on how to correctly use the basic_rate setting in mac80211 with OpenWRT. I've not found much that's OpenWRT-specific, so I'm documenting my experience here. My experience is limited to the ath9k driver and Barrier Breaker. I've not been in a position to test ath5k or ath10k yet. I'd admit that though I've messed around with this stuff a lot, I'm certainly not an authority on the topic, so if I make some factually incorrect claims please point them out.
[Edit 2015-04-15: I can confirm that the basic_rate setting also works for ath5k under Barrier Breaker. It does not work for madwifi. It is likely that it will work for ath10k, but as I've come to realise ath10k is 802.11ac only and therefore does not support the 2.4Ghz band. This means that the slowest basic rate would already be 6Mbps, per 802.11a.]
My motivation is that I want to improve "efficiency" in a generic sense for moderate to high-density 802.11g and 802.11n 2.4 Ghz environments. Mostly from corporate experience, I know that APs transmit beacon frames at the lowest basic rate configured, and increasing bitrate for beacons by disabling the legacy 802.11b basic rates allows for more airtime to be available. This is mostly relevant if there are many APs or virtual APs in close proximity, such as in dense office areas, or possibly with mesh networking. By default, the 802.11b 1Mbps rate is used for beacon transmissions in almost all cases, which is quite inefficient. (Also worth noting is that setting the SSID to "hidden" does not disable the transmission of beacons for that SSID.)
[Edit 2015-04-01: Something else I've learnt is that frames sent at 1Mbps always use Long-Preamble, regardless of whether the hardware type is set to 11g. This makes disabling at least the 1Mbps basic rate almost a no-brainer.]
Slower beacons mean more overhead. Faster beacons mean more airtime for clients, though if you have borderline clients that cannot decode OFDM frames due to low Signal-to-Noise ratios (say, less than 10dB SNR), then these clients might not be able to see the AP beacons, effectively reducing coverage range. In an environment densely packed with APs where it makes sense to make this change, this is usually not a concern.
So, on to how to configure this, given the sparse configuration examples available. The official Wiki guidance is that this must be set per-radio in the wifi-device section and configured as a "list". This is somewhat contrary to some enterprise wireless solutions, where it's set per-SSID, and is something I would like to investigate in future. The format that worked for me is:
config 'wifi-device' 'wlan0' ... list 'basic_rate' '6000' list 'basic_rate' '9000' list 'basic_rate' '12000' list 'basic_rate' '18000' list 'basic_rate' '24000' list 'basic_rate' '36000' list 'basic_rate' '48000' list 'basic_rate' '54000' ...
Note the use of "list", rather than "option", and separating the values into multiple lines. This is contrary to most of the other examples I've found, but I can confirm that the above example works.
[Edit 2015-04-01: I can confirm that having all the options on a single line separated by spaces also works, in the format "list 'basic_rate' '6000 9000 12000 18000 24000 36000 48000 54000'"]
If you're changing the rates beacons are transmitted at, it is probably also advisable to adjust the multicast rate, which is done on a per-SSID basis in the wifi-iface section:
config wifi-iface ... option 'mcast_rate' '6000' ...
Changing the list of basic rates does not affect the list of supported rates. This leads to the confusing situation where most wireless monitoring tools report that the AP still supports connections using legacy 802.11b rates, in spite of the user believing they've disabled it. My motivation was simply to change the rate at which beacons are transmitted, so I don't particularly care which rates are "supported". It is possible to confirm that the basic_rate setting has been sent to the driver by validating that the relevant entries have made their way into /var/run/hostapd-*.conf; look out for the following line; the values are given in 100Kbps format: (note: the OpenWRT option is basic_rate, which is translated to basic_rates in hostapd-*.conf)
basic_rates=60 90 120 180 240 360 480 540
mac80211 also has a "supported_rates" setting, but it doesn't seem like this is configurable via OpenWRT's configuration files. Hence, though the basic rates are restricted, all rates are still listed as "supported."
Neither "basic_rates" nor "supported_rates" affect HT (high throughput, 802.11n) rates, impacting only on legacy rates. So basically, allowing only 6Mbps as a basic rate will still allow you to connect at 270Mbps on MCS 15 with 40Mhz channels and 2x2 MIMO. It is not necessary (or possible, really) to add HT rates to the list.
Validating that beacons are now actually transmitted at the higher rate seems to be tricky. You may be able to use compatible wireless adapters/drivers/OS to capture the raw frames and examine them, but my entry-level Windows notebook certainly isn't capable of that (it reports all frames as being 5.5Mbps and that's that), and neither is the USB adapter I sometimes use for surveys. Maybe someone has some other suggestions.
For this test I was fortunate enough to have access to a spectrum analyser and was able to confirm that the settings above resulted in beacon frames switching from 1Mbps DSSS modulation to 6Mbps OFDM modulation - changing the RF pattern from a "dome" to a "flat-top". I was also able to confirm that the level of overhead introduced by the beacons dropped significantly, which was my goal. Note the "Utilisation (%)" graph below each of the traces.
For the pictures below, I had two APs on the same channel, each with one SSID. One AP was slightly further away from the spectrum analyser than the other, thus you'll see two "domes" and two "flat-tops", one at ~-50 dBm and another at ~-65dBm. The smaller domes at channels 3 and 9 are just the side-lobes of the DSSS-modulation signal; the OFDM sidelobes look quite different, tapering off more gradually.
Transition from 1Mbps to 6Mbps Beacons: (time progresses from bottom to top)
(PS: due to another experiment I was running at the time, the images reflect a beacon interval of 1024ms, rather than the default 102.4ms. This would not be advisable in most situations, but does not affect the general gist of the visualisations.)
(Last edited by atom on 15 Apr 2015, 23:43)