IEEE 802.11s and 802.11r/k/v/w

Installing and Using OpenWrt
1

My current configuration I am running has Gargoyle installed on a WRT3200ACM connected via LAN ports to a WRT1900AC router using a set of Ethernet over Power (SERCOM) adapters. If I can figure out how to fish wires in my wall, or perhaps use some prior CATV holes, I plan to run CAT6 directly betwixt the routers. Failing that, I will try to link the routers using 802.11s as meshed.

My intention is to first load OpenWRT onto the WRT1900AC and migrate all the services I use over to it (DHCP leases, OpenVPN server, DDNS updates, port forwarding, etc…). Once all those services work, I’d like to replaced Gargoyle with OpenWRT on the WRT3200ACM and then migrate all the services back to the WRT3200ACM so it can be my primary router. I would then make the WRT1900AC a “dumb router” (AP only), though still connected in whatever manner worked best, Ethernet over Power, CAT6, or mesh (CAT6 being the best choice of the group of course).

My next phase of the migration would be to get not only 802.11s (mesh) working (as described herein above), but to get 802.11r/k/v/w going too (the current stable version of Gargoyle lacks support for these features as well as 802.11s) without some unsupported contortions to get them to work so OpenWRT is my direction now.

Here are some of my questions:

  1. If I am running OpenWRT on a WRT1900AC and then want to move my configuration to a WRT3200ACM can expect most things to be as they were after such a backup/restore?

  2. What if I am moving from OpenWRT on a WRT1900AC to some other router platform with a different chipset manufacturer or different chipset family from the same chipset manufacturer and use a backup/restore?

  3. I am interested in setting up 802.11r, 802.11v, 802.11k and 802.11w – which if any have hardware dependencies where I need a certain chipset to leverage them? I know the client device must support these protocols too, and my main concerning device, my iPhone SE 2020, has support for all these protocols as far as I understand it.

  4. Regarding 802.11r specifically, I know all the SSIDs (ESSID) must be the same across all of the routers and I understand that the mobility ID must also be same across all routers too. I know how to set both of these configuration parameters within LuCI currently. I think there is a checkbox for 802.11r also in LuCI but I have yet to confirm is has the same impact as the uci set statement herein below or if it impacts other parameters as well.

I am thinking to setup the 2.4GHz band with one set of SSIDs/mobility IDs, and the 5GHz band with a different set.

  1. I have read that the following code will turn this stuff on, but what of the following code can be turned on or off via LuCI also? Moreover, is this code correct?
uci set wireless.default_radio0.ieee80211r=1;
uci set wireless.default_radio0.ieee80211k=1;
uci set wireless.default_radio0.ieee80211v=1;
uci set wireless.default_radio0.ieee80211w=1;
uci set wireless.default_radio0.bss_transition=1;
uci commit;

  1. What kind of overhead does installing luci-app-dawn exert upon the router and what advantages do I gain from installing it given I am on OpenWRT 21.02.1?

  2. Does dawn need to run on just the dumb APs in the network or on the Primary AP as well?

  3. I understand that mesh networks ought all run on the same channel, whilst two different WiFi networks (for clients) on two different routers should run on different channels, is this correct? Is there any difference betwixt using these methods for 2.4GHz vs 5.0GHz?

  4. As currently, configured my 2.4GHz networks and my 5.0 GHz networks have different ESSIDs and mobility domains (all 2.4GHz networks have SSID “wifi-lan-2.4” and a mobility ID of 1234, where all 5.0 GHz networks have SSID “wifi-lan-5.0” and a mobility ID of 4321). Does this methodology make sense or can it be improved?

  5. The same is true for the mesh networks, there is “wifi-mesh-2.4” and wifi-mesh-5.0”. Same question in this instance too? Obviously, there is no mobility ID for 802.11s networks.

  6. What happens if you have different SSIDs with the same mobility IDs?

Thanks in advance!

2

I added some PRs to get k and v GUI support. r is in the GUI - just turn it on, and give each AP a unique NAS-ID, and same mobility domain, i.e. default. Everything else is auto.

If you want backup/restore parity - ensure that radio numbering is identical across the platforms. It isn't always.

Only briefly looked at DAWN - cannot comment on it. vkw all need software support - iOS 8 and newer, Android 7-8 and newer should be OK.

Never tried mesh. A weakest link slows the whole thing down. I do wired backhaul with dumb APs.

I recommend different SSID for 2 and 5GHZ. That way, if not all AP have 5 GHz or client cannot do 5GHZ, then devices don't get 'stuck' on a far away AP at roam time because something closer only has 2.4 or 5 or whatever.

Read up. 802.11v=1 does nothing any longer (bad for grouped GUI design, I think). You need to activate individual v features.

Recommended reading about channels.

11: try, and find out. Likely nothing: what happens with two Johns in two different cities?

Top points for correct use of betwixt. :+1:

3

Thanks for PRs on k and v, having stuff in the GUI is always more helpful as command line configurations can change and docs seem not to be clear on setting up roaming so much.
I am running 21.02.1, do you know what version will next have these PRs inclusive to it or when they might become available as an update?

By radio numbering, you mean "radio0" being 2.4GHz vs 5GHz, or the radio numbers having a numbers other than 0 or 1?

I will read and study more about dawn but hopefully someone can post a link with helpful info on setting it up.

I agree on 802.11s/mesh as a wired backhaul is truly the superior way to get it done. For now, I am using Ethernet over Power but that is slower than direct Ethernet wires, which will be my next step in this regard.

I have taken your recommendation into consideration and created two different SSIDs for the 2.4GHz network and 5GHz network. However, the "Read up" link you sent me seems to suggest that if two different APs (one primary and one in dumb mode) have two different SSIDs and the same mobility ID (for the same band, say 2.4GHz) they will roam and you can more easily know which AP you are connected to. Can you speak to this at all?

I should remove the ieee80211v=1 from my configuration then, as it now longer has any impact you are saying? So what is the proper way to enable 80211v if the 80211v = '1' entry is wrong and should be deleted?

Am I also understanding that it is best to allow OpenWRT to be in auto channel mode even when roaming is being used? I read elsewhere that you had to pick specific channels when using roaming, I suppose that was wrong information. Granted, auto channel mode would seem the most prudent presuming it does not interfere with the proper operation of 802.11r functionality.

If I am using 802.11s is auto channel selection okay for both APs to use for that network?

Thanks in advance for your comments.

4

Proper way to do it now is adding to your /etc/config/wireless:

option bss_transition '1'

Following you can see an example of my configuration including what you plan to enable:

config wifi-iface 'wifinet1'
	option device 'radio1'
	option mode 'ap'
	option ssid 'Desastre'
	option encryption 'psk2+ccmp'
	option dtim_period '3'
	option key 'no.esperes.la.de.verdad'
	option network 'lan lan6'
	option macaddr '3C:61:70:3E:3A:8E'
	option ieee80211r '1'
	option nasid '3C61703E3A8E'
	option mobility_domain 'baba'
	option ft_psk_generate_local '1'
	option ft_over_ds '0'
	option reassociation_deadline '20000'
	option wds '1'
	option ieee80211k '1'
	option bss_transition '1'
	option wnm_sleep_mode '1'
	option time_advertisement '2'
	option time_zone 'AEST-10AEDT,M10.1.0,M4.1.0/3'

Note: Enabling ieee80211k does not require you to enable rrm_neighbor_report nor rrm_beacon_report, they are enabled automatically in hostapd.sh.

Regarding

I believe that is much better that you select manually the less congested channel. Channel auto select algorithms aren't great.

Doubt it, for 802.11s both stations must be on the very same channel. Not sure they will automatically choose the same channel. Another consideration for you is to try how efficient is 802.11s, I ran it for a while and discovered that there is a big difference in throughput so, ended going with 4addr (WDS), is stable and throughput increased by 200 Mbps (mostly doubled in several scenarios), seeing that you only have 2 devices, this is your best path, IMHO.

I hope this helps.

5

Amteza,

Are you running 21.02.1 firmware version? I think maybe some of the settings names changed from an older version?

6

Sure am. I checked all the setting names before replying, all are correct, you can check it by yourself in /lib/netify/hostapd.sh, it's a good place to double check when in doubt. And, just seeing all the features enabled in WiFi Explorer, BTW.

7

I have no /lib/netify directory.

But this is ​what I have:

root@wrt1900ac:/# find / -name 'hostapd.sh' -print 2>/dev/null
/lib/netifd/hostapd.sh
/rom/lib/netifd/hostapd.sh
root@wrt1900ac:/#

Both appear to be scripts not configuration files with parameters in them.

8

Yeah, sorry forgot the "d". You are correct, it is a script, but you can check what parameters get read from your configuration files, see below:

        json_get_vars ieee80211k rrm_neighbor_report rrm_beacon_report
        set_default ieee80211k 0
        if [ "$ieee80211k" -eq "1" ]; then
                set_default rrm_neighbor_report 1
                set_default rrm_beacon_report 1
        else
                set_default rrm_neighbor_report 0
                set_default rrm_beacon_report 0
        fi

As an example you can see ieee80211k gets read, processed and in case it's value is '1', the other two parameters I referred to get enabled.

1 Like
9

cannot comment on openwrt behaviour for channel=auto for adjacent APs - usually the AP will try to find the quietest channel for where the AP is, but for infra, you usually want to have same SSID on different channels for adjacent APs to improve roaming. Often, the best way to achieve this is manual cfg.