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'
     ...

(Refer: http://wiki.openwrt.org/doc/uci/wireless)

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.

1Mbps Beacons:

6Mbps Beacons:

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.)

Some references:
* http://en.wikipedia.org/wiki/IEEE_802.11#Protocol
* http://www.revolutionwifi.net/revolutio … lator.html
* http://www.revolutionwifi.net/revolutio … pping.html

(Last edited by atom on 15 Apr 2015, 21:43)

So what wood it look like this?

config wifi-device 'radio0'
     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'
    option type 'mac80211'
    option path 'platform/ar934x_wmac'
    option hwmode '11ng'
    option htmode 'HT40-'
    option channel '6'
    option txpower '25'

config wifi-device 'radio1'
    option type 'mac80211'
    option hwmode '11a'
    option path 'pci0000:00/0000:00:00.0'
    option channel '44'
    option htmode 'HT40+'
    option txpower '25'

config wifi-iface 'ap_g'
         option 'mcast_rate' '6000
'option device 'radio0'
    option mode 'ap'
    option network 'lan'
    option disassoc_low_ack '0'
    option ssid 'tapper'\''s net'
    option encryption 'psk2'
    option key '******'

config wifi-iface 'ap_a'
     option 'mcast_rate' '6000'
    option device 'radio1'
    option mode 'ap'
    option network 'lan'
    option disassoc_low_ack '0'
    option ssid 'tapper'\''s net'
    option encryption 'psk2'
    option key '*****'

(Last edited by tapper on 30 Mar 2015, 20:47)

for the linux OS side you probably should have a look at radiotap
https://wireless.wiki.kernel.org/en/dev … n/radiotap

btw - afaik the drawbacks of 802.11b were worked on in the n/ac standard.
But like the Beacon/Multicast rate adjustment there are incompatibilities involved with legacy equipment.
5GHz short range high bandwidth and long distance links might not be that compatible from protocol design point of view.

tapper:  that looks about right.

zloop:  thanks for the tip re. radiotap headers.  Based on the little bit I read over the past few minutes, it unfortunately looks like my Ralink-based adapters' drivers don't support radiotap, but will see if I can find another adapter to test with.

802.11ac is 5Ghz-only.  The older 5 Ghz standard, 802.11a, never had the legacy DSSS rates, so it (802.11ac) doesn't have to deal with this particular "problem". The legacy 1, 2, 5.5 and 11 rates were only part of the original 802.11b (2.4 Ghz) specs.  Disabling these rates make 802.11g similar to 802.11a (except of course for the frequency-thing.)

So the way that 802.11ac deals with drawbacks is by avoiding them entirely :-) it eliminates the use of 2.4 Ghz and the DSSS-legacy rates altogether.  The lowest basic rate on 802.11ac (and 802.11a and 802.11n/5Ghz) is 6Mbps, so that is (by default) what beacons would be transmitted at.

802.11n on 2.4Ghz maintains full backwards compatibility by default.  That means that beacons are transmitted at the lowest enabled basic rate - 1Mbps by default.

Adjusting rates in the manner described only makes it incompatible with 802.11b equipment.  However, I don't have any 802.11b equipment in my environment and don't need to cater for the possibility, so it doesn't affect me.

[Edit 2015-04-08: Corrected typo.]
[Edit 2015-04-24: Corrected missing 11Mbps rate amongst list of legacy 802.11b rates]

(Last edited by atom on 23 Apr 2015, 23:21)

Ignoring that the changes I described don't impact 5Ghz, I'm curious why you'd anticipate issues on such links, and also which protocol you're referring to?

(Last edited by atom on 31 Mar 2015, 08:46)

Interesting topic i never thought about, thanks.

On TPLINK WDR4300 running CC 15.04.01 I have tried on both radio0 and radio1:
list supported_rates '12000 18000 24000 36000 48000 54000'
list basic_rate '12000 24000 54000'

After restarting wifi:
on 2.4Ggz interface: Bit Rates:12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s; 48 Mb/s; 54 Mb/s
but 5.8 Ghz interface: Bit Rates:6 Mb/s; 9 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s; 48 Mb/s; 54 Mb/s

Why is 5.8Ghz radio still showing 6 and 9Mbps rates?

Found a bug and reported it here - https://dev.openwrt.org/ticket/18627

look how those spread across freq. spectrum and it's only a beacon. imagine what it looks like when real data transfer takes place.

for a reference i can say that while running 2.4GHz uplink to remote AP on CH13 with 24dbi directional antenna still makes it impossible to use CH1 at full 802.11g capacity for local side access if your local radio is close to uplink radio and antenna.

even lowering local side freq. to something like 2352MHz still resulted in some interference from uplink on CH13 which finally disappeared somewhere around 2322MHz.

anarchy99 - yeah, what happens on the physical layer is surprising, fascinating - and completely over my head!  Interestingly, I had something like that recently where a poorly-configured in-building 1.8 GHz GSM repeater was too close to my AP and created significant problems.  Separating antennas by another meter or two was a big improvement.

valentt - interesting; I wouldn't expect there to be much benefit to increasing the basic rate from 6Mbps to 12Mbps, as the beacon overhead is already quite low at 6Mbps.  The main reason I've found for disabling rates <= 5.5Mbps is that they use DSSS/CCK, which is supposedly less effecient in terms of spectrum use.

Other than the "best practice" claim by someone else in the bug report you link to, do you have any technical justifications for disabling the 6 and 9 Mbps rates?  I know some have tried to do so in the past to try to control coverage area, but I recall discussions that there may be other, more appropriate solutions.

@atom I'm also just experimenting and trying to get hands on experience with controling coverage area, so if you have any info or if you can point me in right directions of existing discussions regarding this topic that would be great.

(Last edited by valentt on 4 May 2016, 20:27)

Depends on what you want to achieve, I guess.  If your intent is to influence the way clients roam between APs: that's a very tough nut to crack.  From what I've been able to read and experience, client devices largely control their own destiny. Large vendors with controller-based solutions have some (read: limited) mechanisms and 802.11k promises some hope of standardisation in that space, but ultimately the client device decides...

I can't find the specific debate someone had with a developer I seem to recall, but assuming the above is what you're curious about, as a starting point I can recommend searching on "sticky clients" and "rssi threshold".  A blog post I've found that covers this quite extensively and seems to be rather well written is this:  http://wifinigel.blogspot.com/2015/03/w … ients.html

Using

iw dev wlan0 station dump

I see some stations are connected at

tx bitrate:     1.0 MBit/s
rx bitrate:     1.0 MBit/s

Is it something to consider when changing basic_rates? I mean, won't there be too many frame retransmissions that will nullify the positive effect of faster beacons?

basic_rates does not change supported_rates, which is something separate.  Stations will still be able to communicate at 1 Mbps, and will likely remain associated for as long as they can successfully decode a higher-rate beacon frame every now and then.  Per valentt it's might be possible to "shake" those clients if you up the beacon rate even higher, but I've not done much reading/testing about the real effect of doing so.  My recollection is that it's not always a great idea, as it's theoretically better for clients to detect 802.11 frames rather than "noise."  I suspect any attempts to decrease coverage in that way should be done in conjunction with judicious decreases in transmit power.  It's usually a good idea to try to match AP transmit power with that of the client devices.  A typical phone/laptop has an transmit power of about 16 dBm in the 2.4 GHz band.

Regarding positive effects: the stations you mentioned would be marginal whether or not you have beacons transmitted at a higher rate so I don't quite see the relation between the two points you mention; beacons are broadcasts, and they don't get "retransmitted."

Having said that, operating at 1 Mbps isn't a guarantee of a poor connection and its real impact would depend on the volume of traffic flowing over that link and - as you state - whether the SNR (~RSSI) is low enough to cause significant retransmissions.  I have for example seen well-connected mobile devices switch to a 1 Mbps transmit rate, presumably as part of some client-side power saving mechanism.

am having a challenge trying to force multicast (on 5ghz) to run at a higher rate (and additionally, to confirm that it is running higher).
These options do not seem to work:
   iw dev <devname> set mcst_rate XX
   iw dev <devname> set bitrates

any recommendations?

and is there a way to confirm the actual setting if/when it is set?

(Last edited by wifinix on 9 Jan 2017, 23:43)

I've never found a reliable way to play around with multicast, so have never really been able to test it.  Just been going on what the documentation says is supposed to happen... How are you testing?

Theoretically, multicast data will be sent at the lowest basic rate.  That is, by default Multicast should happen at 6 Mbps on 5 Ghz.

Of interest may be that recent builds of LEDE contains Multicast-to-Unicast conversion enabled by default.  This will send multicast traffic at the optimal rate for the station.  This is good if you have few, fast stations, bad if you have lots of slow stations receiving multicast data.

thx for the quick reply.
1. testing process:
- i've got a streaming server on a LAN port, serving multicast.
- have 4-6 client stations.
   
  it's pretty obvious to me that it's still sending as Unicast, as it gets worse with every additiona device running.

have not been able to turn it off.  any ideas on that?

2. the GUI is showing 6MBit.
iv'e tried the settings as shown, and get no feedback (good or bad), so unsure if it's actually changing.  obviously the fact that it's still flipping to unicast has an impact, and i've been unable to force it to stay multicast.

3. I need to force multicast AND force to say 12 or 16Mbits (for a handful of reasons, which i don't want to waste bandwidth to discuss).

All my stations are identical - fast and new (and I'm actually able to manage this) - this is a closed network for a specific purpose (not something for the general public)...

my initial theory was to simply force a higher basic rate. have never succeeded on 5ghz... Any thoughts?

thx!

I'm a little light on how exactly what you place in config files get translated to actions, but if my understanding is correct then hostapd does the actual work at the back.  Most of what one sets in /etc/config/wireless ends up in hostapd-*.conf files in /var.  So if there's no multicast setting there, chances are it won't be applied to the radio.

Also, in a mailing list I follow, it was suggested that changing the value of  the following *might* turn off multicast to unicast conversion: /sys/class/net/br-lan/lower_wlan0/brport/multicast_to_unicast

(That is, try running "echo 0 > /sys/class/net/br-lan/lower_wlan0/brport/multicast_to_unicast")

thanks so much.

1. tried the echo... no dice ('permission denied')....
2. here's the relevant parts of my /etc/config/wireless

config wifi-device 'radio0'
        option type 'mac80211'
        option channel '36'
        option hwmode '11a'
        option path 'pci0000:01/0000:01:00.0'
        option txpower '23'
        option country 'US'
        option htmode 'VHT4i0'
        list supported_rates '18000 24000 36000 48000 54000'
        list basic_rate '18000 24000 54000'

config wifi-iface
        option device 'radio0'
        option network 'lan'
        option mode 'ap'
        option encryption 'none'
        option ssid 'SSIDNAME123'
        option mcast_to_ucast=0                               
        option mcast_rate '18000'

am not sure i've even patched the parts in the correct area... documentation on this part of the world seems rather iffy.... thoughts are greatly appreciated.

Multicast to Unicast conversion has been enabled by default on bridged WiFi AP interfaces for about a year.  This is on OpenWRT and LEDE.  This is meant to prevent the sending of multicast data at a slow rate which impacts the performance of WiFi networks.

That is why you are seeing multicast data being transmitted at a higher rate.

Removing your WiFi interface from the bridge would solve the problem, but you would lose the simplicity of a bridged Ethernet and WiFi network.

Maybe changing
/sys/class/net/br-lan/lower_wlan0/brport/multicast_to_unicast

to 0

would solve your problem and still allow you to keep your Ethernet and WiFi interfaces bridged.

Two possible reasons that you get "access denied" are that you're running an older build of OpenWRT which does not contain that directory, or that your bridge is not called br-lan.

In case your bridge name might be different:  you can run "brctl show" to see all the bridges that are defined.  Also have a look in one of the parent paths (/sys/class/net/) to see if you can spot your bridge's name (br-lan by default.) 

Then change directory to /sys/class/net/<** bridge name***>/lower_wlan0/brport", verify that the "multicast_to_unicast" "file" exists (you might be on an older build where that did not exist), and - if it exists - do "echo 0 > multicast_to_unicast"

You're quite right, this setting would not survive a reboot.  You can put something in /etc/rc.local to address that, as I suspect that might not be exposed in the config file structures yet.

Thanks.. We have added the changes to /etc/rc.local, to force it to 0.. and we've confirmed it IS staying at 0 (post reboot)...

However....My rudimentary multicast test is still confirming packets are actually going unicast.

(test is this: we stream extremely high packet load to 1 device, check for latency/lost packets, then add 2nd adn 3rd device, checking for loss...... we're losing more packets with every added device...)

Edit: I should add that the bridge name is correct as well..

Any other way to force basic rates higher (and force true multicast)

(Last edited by wifinix on 12 Jan 2017, 05:59)

Hmm so what throughput rates are you seeing for a single station test?  With what you set in the config, the multicasts should be happening at 18000 Kbps symbol rate, which should give you in the region of 9-12 Mbps throughput (have a look in LuCI on the Status --> Realtime Graphs --> Traffic --> wlan0 page.)  If things were running with defaults (other than multicast optimisation=off), I would expect a symbol rate of 6000 Kbps, though as I've stated I've never tested this myself.

Also, is this IGMP multicast or some other Layer 2 multicast?  I have no way of trying to reproduce this myself at the moment, but if it's IGMP, you might need also need enable IGMP Snooping first.  I've found a fairly well-written wiki on it:  https://wiki.openwrt.org/doc/howto/udp_multicast

There also appears to be stats-stuff that could potentially be useful for troubleshooting in /proc/net, notably /proc/net/igmp and /proc/net/dev_mcast.  Although I didn't find anything related to multicast there, you could also scratch through /sys/kernel/debug/ieee80211 to see if something seems useful to you.

thx..
the goal would be true layer2 multicast, with as little 'software' or processing as possible (lowest latency possible is being sought).   I don't really think we want IGMP, due to the additional processing required...

Additionally, we really don't need snooping - we are trying to send multicast over wifi, NOT just over ethernet. our concern is to:  a. prevent latency by packet analyzation, and b. sent mcast packets at higher rate than minimum..  IGMP doesn't really answer this second issue..