[Solved] 802.11r configuration details (R7800)

Installing and Using OpenWrt Network and Wireless Configuration
1

I've started to experiment with 802.11r and looking in to the different options. And would like some input. I am deploying this on a Netgear R7800 running latest trunk release.

  1. Should access points with same SSID and mobility domain also share the same channel?

When searching on deployment guides I stumbled upon a Cisco recommendation saying that WiFi clients will Not probe all channels on the card to find a neighbouring router. Again, using the same channel and ssids might create a channel conflict and disruptions. I cannot find the document again, but it could be that this was related to 802.11k and not 802.11r.

I have not found any recommendations around channel distribution in 802.11r. My guess is that I should in fact select different channels.

  1. VHT160 channel selection

Related to above on 5GHz I utilize VHT160. As far as I can understand there are two supported VHT160 channels on 5GHz; Channel 36 and Channel 100*. However, looking at regulatory domain data I cannot find that VHT160 is supported on Channel 36 for my (or any?) regulatory domains. Will channel 36 work properly for VHT160?

Related to question #1 in case I need to separate the channels.

[*] http://www.revolutionwifi.net/revolutionwifi/2013/03/80211ac-channel-planning.html

  1. Is FT over the Air or DS recommended?

I found** the following description around the FT protocol;

For a client to move from its current AP to a target AP using the FT protocols, the message exchanges are performed using one of the following two methods:

  • Over-the-Air—The client communicates directly with the target AP using IEEE 802.11 authentication with the FT authentication algorithm.
  • Over-the-DS—The client communicates with the target AP through the current AP. The communication between the client and the target AP is carried in FT action frames between the client and the current AP and is then sent through the controller.

Based on this description and the fact that I don't have a controller, Over-the-Air should be the preferred method? It might be that the cisco documentation of a controller is very ciscoified and the OpenWRT definition might work completely different.

[**] https://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/80211r-ft/b-80211r-dg.html

  1. 802.11r vs 802.11s

How does 802.11r differ to 802.11s? What I am really after is fast handover and for the client to always connect / roam to the strongest signal access point at the time in the network.

I see a fairly uncompleted document*** on 802.11s on OpenWRT. Is it fully supported?

[***] https://openwrt.org/docs/guide-user/network/wifi/mesh/80211s

  1. Is 802.11r and 802.11s compatible?

  2. External R0/R1 Key Holder List

I see the option for External R0 Key Holder List which should according to information be configured to other R0KHs in the same mobility domain. Is this relevant or will leaving it empty make this exchange work? Again this refers the FT control mechanism.

  1. Validation of operation

How can I in OpenWRT from CLI or UI validate that 802.11r is working and authentications are being exchanged? And/or get logs of client interoperability with the 802.11r features enabled?

Thanks :slight_smile:

2

I wouldn't recommend it.

I would suggest the easiest way to find out is to try it. Do you have any clients that support VHT160? From my research, albeit some time ago, it seemed there was very little client support for it, nor were the benefits that great even when it was supported.

I use over DS in my setup (just OpenWRT devices, no controller). Tried over the Air for a while. Saw no difference.

802.11s deals with mesh setups. 802.11r deals with fast handover. For what you're after then 802.11r is the way to go.

Use the 'Generate PMK locally' option. Means you don't have to configure any R0/R1 options.

Not sure how to validate in OpenWRT, but you can do it on client devices with the correct software. If you have an Android device you can use Wifi Analyzer to see if the access point reports 'WPA2-PSK+FT'

1 Like
3

What’s nice is that you just have click the 802.11r toggle in the GUI and it just works. No further advanced configuration needed for a home / small network.

Agree with all of krazeh’s responses. My two r7800 APs are setup like this, 80Mhz non overlapping and non DFS channels:


root@OpenWrt:~# cat /etc/config/wireless

config wifi-device 'radio0'
        option type 'mac80211'
        option channel '36'
        option hwmode '11a'
        option path 'soc/1b500000.pci/pci0000:00/0000:00:00.0/0000:01:00.0'
        option htmode 'VHT80'
        option txpower '22'
        option legacy_rates '0'
        option country 'US'
        option beacon_int '101'

config wifi-iface 'default_radio0'
        option device 'radio0'
        option network 'lan'
        option mode 'ap'
        option ft_over_ds '1'
        option ssid '*********'
        option ft_psk_generate_local '1'
        option key '************'
        option ieee80211r '1'
        option encryption 'psk2+ccmp'


root@OpenWrt:~# cat /etc/config/wireless

config wifi-device 'radio0'
        option type 'mac80211'
        option channel '161'
        option hwmode '11a'
        option path 'soc/1b500000.pci/pci0000:00/0000:00:00.0/0000:01:00.0'
        option htmode 'VHT80'
        option txpower '22'
        option legacy_rates '0'
        option country 'US'
        option beacon_int '101'

config wifi-iface 'default_radio0'
        option device 'radio0'
        option network 'lan'
        option mode 'ap'
        option ft_over_ds '1'
        option ssid '**********'
        option ft_psk_generate_local '1'
        option key '************'
        option ieee80211r '1'
        option encryption 'psk2+ccmp'
1 Like
4

@krazeh: Whoop, thanks for excellent and crystal answers!

@ACwifidude: Thanks!

As for VHT160 I decided to reconfigure using channel 36 + 100 non-overlapping. I will however after your recommendations try out reducing it to VHT80 to see any performance differences. As @ACwifidude mentioned you can avoid DFS channels this way.

As for this thread I think the only outstanding question would be functionality of 802.11r and 802.11s in combination. @krazeh: you mentioned that I want to have 802.11r in a case of a fast handover to the strongest signal available. How will this differ from a mesh network operates towards the client?

Thanks for a very quick turnaround. :slight_smile:

5

Mesh just means a wireless connected station / AP. Mesh doesn’t require handover capabilities (r/v/k) but most boxed systems often do offer those capabilities (handover capabilities are independent of a mesh). Mesh is a compromise - Mesh = “you can’t run a cable and need a connection so you setup a wireless connection“. Advantage is convenience, disadvantage is performance.

I’d instead opt for a hardwired backhaul (I’m using cat 6A cables) with 802.11r/v/k handover capabilities and avoid everything mesh.

1 Like
6

Thanks! Crystal clear. :slight_smile: Same with my deployment.

While I have enabled and focused on 802.11r, based on this post I might still have some way to go for the optimal solution though enabling 802.11v/k. Everyone needs a good weekend project I suppose. :smiley:

7

Unless you have a significant number of APs over a large area I'm not sure how much value you would gain from adding v/k. But it might be a fun project to try..

8

Two over a quite small area. :slight_smile: I basically put up the second one because of bad coverage by the 1st AP on all of my my back yard. Definitely for the fun project part.

9

Just did a quick test. Had my laptop in the back yard. Walked it in across the apartment and sat it down to the other AP in the other side. No doubt it would have a stronger signal. Still it's sticky to the AP in the livingroom.

Any threshholds I can configure when clients should jump to a stronger AP?

10

Clients determine the threshold of when they transition. The transition is determined by the strength of signal. Two ways you can tweak that is router/AP physical positioning (high and away from obstacles to optimize radio) and tweaking the transmission power. If you have a mix of roaming devices you’ll have to make some compromises to optimize all clients. I recommend you use different names for 2.4ghz SSID and 5ghz SSID. Use the 5ghz SSID for phones / laptops / roaming devices to optimize performance and optimize roaming for only one radio frequency (2.4ghz is “longer and slower”, 5ghz is “shorter and faster”, I’d rather lose a couple dBm with 5ghz and have double the speed)

You’ll probably have to turn down your transmission power on one or both your APs depending on your layout. Definitely don’t use any auto settings.

Ex: iOS devices transition at - 70 dBm so I optimized my router positioning to be high and away from obstructions. I then turned down my transmission power to 22 for my 5ghz radios for my space - this gave me ~67 dBm at the middle transition spot so that devices would handover nicely.

2 Likes
11

@ACwifidude, thanks for the input!

I do have different names for 2.4 and 5GHz networks. I have however selected regulatory domain Panama to be able to crank up txpower to 1000mW on both access points for both 2.4 and 5GHz. Pretty much figuring; "more is probably better". (also; the regulatory domain does not have any DFS scanning requirements :wink: Good for VHT160. But I guess clients would disconnect/limit output if it detected a radar frequency being used).

Either case; It's a good suggestion to force a handoff. And as far as I understand I would still not benefit from 802.11v/k for this particular scenario. Do correct me if I would be mistaken :slight_smile:

12

You’ll probably get better roaming performance and throughput performance turning it down. Clients usually have weak radios. Making a long shot to an access point slows all other devices down while they wait on far away / weak clients.

A quick survey of RSSI levels for your environment can help you be more exact on the transmission levels to get an optimized setup. Just walk around with an app that measures RSSI levels every couple feet. I’d turn it down so that you get the right balance of RSSIs to get the behavior you want.

This is a great read on PHY and understanding that the client is the weak point of all wifi systems:

https://www.duckware.com/tech/wifi-in-the-us.html#realitycheck

Here is a good quote from the summary (chapters 16 and 17) of the page:
“ Increased range is NOT always a good thing: I was reading a post by someone exclaiming the merits of some new router because range was twice that of his prior Ruckus AP's and he was installing at an airport. That may be true, but counterintuitively, increased range in dense (lots of clients) environments is absolutely NOT a good thing. And once you think about it, it makes sense. Everyone on an AP shares that AP's wifi bandwidth. Period. Which is exactly why you want shorter wifi range and more AP's in dense environments -- so fewer people per AP means INCREASED wifi bandwidth per person. The same principle applies to large homes, where you want everyone evenly connected to several AP's, not everyone connected to one AP.”

1 Like
13

Awesome! Thanks for the link and resource. :slight_smile:

One of the reasons why I wanted to crank up my txpower was not just because of my clients, but also for my open SSID FREE_WIFI. It's as the name describes a fully open network. With the caveat that all traffic entering is routed out over TOR.

This allows me to contribute to anyone in need of some wifi along the way while still not getting in trouble for whatever someone may want to do with my connection.

As such I would like this to span as far around as possible. So far this year I've had 114 unique clients utilizing it.

In the best of words I guess I'd do a site survey with my internal SSIDs on two acces points, and buy one additional one which is only used for FREE_WIFI which can be completely separate from the rest.

1 Like
14

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.