When does 802.11r "FT over DS" make sense to use?

wired · February 17, 2021, 4:50pm

Looking at "FT over DS" and "FT over the Air":

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

It seems to me that "FT over DS" doesn't make too much sense to use. It communicates with the target AP via the current AP. But if the client needs to roam it's because the signal is getting worse, e.g. you're walking away from the current AP towards a target AP. Wouldn't it make sense to start talking to the target AP hence using "FT over the Air" would be better?

Stefan1 · February 17, 2021, 6:20pm

Good question. Up to now I just thought FT over DS is more secure, but that does not seem to be the point.

I found this, also discussing advantages/disadvantages of the 2 approaches:

In short if I understood that paper correctly it looks like ft over ds is the better approach if the network between the APs is not too crowded, because the client only switches channels in case it definitely roams, whereas with ft over the air it has to pause the current ap to contact the new one.

And basically with your nickname "wired" you definitely should choose ft over ds

wired · February 17, 2021, 6:36pm

Great link!
I asked the question because "FT over DS" seems broken now
https://forum.openwrt.org/t/802-11r-broken-in-recent-master-nl80211-attr-sta-vlan-errors/88888

I do not have a controller, so I wonder how the APs talk to each other or "over DS" without some sort of controller just doesn't work?

provided that both APs have a way to communicate. In a controller-based network, no problem.

And from the comments:

I haven't tried 802.11r with standalone APs, as I have a controller. So I can't say much about how (or even if) it actually works, and it's probably somewhat of a corner case, as most people do have controllers anyway.

The best way to make this work without a full blown WLC is probably to look at Mobility Express feature on the new APs, which in 8.2 allows you to run an AP as a cut down controller of sorts. In 8.2 this now also supports FT.

Stefan1 · February 17, 2021, 6:57pm

I use 802.11r together with wpa2/eap on 19.07.6, therefore I have to specify all this key stuff in the wireless config:
mobility_domain, pmk_r1_push, r1_key_holder, r0kh, r1kh...

This all is done somehow automatically if you use wpa2/psk and specify ft_psk_generate_local.

To my understanding the current AP knows the mac addresses of all involved APs (as they have to be all listed with r0kh and r1kh), and with the pmk_r1_push option every access point pushes all info needed for roaming in advance to all involved access points.

This is described here much better than I can do it:
https://blog.fem.tu-ilmenau.de/index.php?url=archives/1002-HowTo-enable-WiFi-roaming-with-hostapd-and-VLANs.html&serendipity[cview]=linear

wired · February 18, 2021, 9:26pm

If I'm reading that post correctly, with hostapd the key is generated locally (for better or worse) so the APs do not need to talk to each other.

With PSK, hostapd can generate R1 locally as it already knows the MSK (derived from passphrase). The passphrase needs to be present, as the client could as well start its session locally. So no inter-AP communication is required.

So maybe DS vs Air does not really matter for WPA2 PSK?

Stefan1 · February 18, 2021, 9:50pm

Yes, that really sounds like that.

Interesting would be to see the hostapd log messages of the target ap after such a roaming.

With ft over ds and wpa2/eap the log entries look like:

Thu Feb 18 21:04:51 2021 daemon.info hostapd: wlan1: STA mac IEEE 802.11: associated (aid 1)
Thu Feb 18 21:04:51 2021 daemon.notice hostapd: wlan1: AP-STA-CONNECTED mac
Thu Feb 18 21:04:51 2021 daemon.info hostapd: wlan1: STA mac RADIUS: starting accounting session CB4359DF9A480957
Thu Feb 18 21:04:51 2021 daemon.info hostapd: wlan1: STA mac IEEE 802.1X: authenticated - EAP type: 0 (unknown)

wired · February 18, 2021, 11:22pm

Have you tried latest master? Do you see any of these errors?

Mon Feb 15 20:08:45 2021 daemon.err hostapd: nl80211: kernel reports: key addition failed
Mon Feb 15 20:08:45 2021 daemon.err hostapd: nl80211: NL80211_ATTR_STA_VLAN (addr=xx:xx:xx:xx:xx:xx ifname=wlan0 vlan_id=0) failed: -2 (No such file or directory)

Stefan1 · February 19, 2021, 6:23am

No, I do not use snapshots. I need a stable working environment, as my complete family relies on internet for work and school. We are in lockdown since 2 months, I work from home since nearly 1 year.
No dangerous experiments yet...

Lynx · November 22, 2021, 3:03pm

What is the latest with this? Does FT over DS work for anyone at the moment? Can it work with a WDS setup?

Keen to hear any experiences positive or negative with using 802.11r.

shaarkys · November 23, 2021, 9:20am

I had to switch over from FT over Air to FT over DS due to some of the devices were randomly loosing connections (in my case Wifi thermostats).

But in general, eg. my Android phone has been roaming fine of both standards...

Lynx · November 23, 2021, 12:34pm

Have you confirmed that it works with the log lines:

WPA: FT authentication already completed - do not start 4-way handshake

In this post:

@hnyman indicated he got things working using FT over the air. @hnyman did you have any success with FT over DS? I gather in theory the latter is preferable?

hnyman · November 23, 2021, 12:38pm

I didn't actually test FToverDS (after realizing the need for the reassociation_deadline change).

I can test it later.

Lynx · November 23, 2021, 1:04pm

Ace, thanks. Do you suppose the present default:

will not work? If not presumably the default should be changed to 20000.

hnyman · November 23, 2021, 1:29pm

It didn't work for me without that change.
(Like I tried to say above in my previous message that you quoted.)

Lynx · November 23, 2021, 2:50pm

Oops, yes indeed - sorry ! Looking forward to testing various options myself too.

hnyman · November 23, 2021, 4:22pm

I tested now also with "FT over DS", and got mixed results. Although the device once switched ok via FT, it didn't later switch back to the original router although the signal was weak.

When I then reverted back to "over Air", the switching between APs was more immediate.

Lynx · November 23, 2021, 5:34pm

Thanks for the information.

Does this look OK to you? I am using x3 RT3200's.

config wifi-device 'radio0'
        option type 'mac80211'
        option path 'platform/18000000.wmac'
        option channel '1'
        option band '2g'
        option htmode 'HT40'
        option cell_density '0'
        option noscan '1'
        option country 'GB'

config wifi-iface 'default_radio0'
        option device 'radio0'
        option network 'lan'
        option mode 'ap'
        option ssid 'XXXX'
        option encryption 'psk2'
        option key 'XXXX'
        option ieee80211r '1'
        option ft_psk_generate_local '1'
        option reassociation_deadline '20000'
        option ft_over_ds '0'

config wifi-device 'radio1'
        option type 'mac80211'
        option path '1a143000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0'
        option band '5g'
        option cell_density '0'
        option channel '36'
        option country 'GB'
        option htmode 'HE80'

config wifi-iface 'default_radio1'
        option device 'radio1'
        option network 'lan'
        option mode 'ap'
        option ssid 'XXXX'
        option encryption 'psk2'
        option key 'XXXX'
        option wds '1'
        option ieee80211r '1'
        option ft_psk_generate_local '1'
        option reassociation_deadline '20000'
        option ft_over_ds '0'

Having set the above on all nodes I saw this on one of my extension nodes:

root@OpenWrt:~# logread
Segmentation fault

Reboot seemed to fix.

The RT3200's don't seem to react very nicely to having WiFi settings changed without reboot. I recall seeing mtdblock2 read errors when switching from mesh to 160Mhz.

I think this looks like it is working for iphone from perspective of single node, right(?):

Tue Nov 23 17:31:33 2021 daemon.info hostapd: wlan0: STA XX:XX:XX:XX:b4:10 IEEE 802.11: authenticated
Tue Nov 23 17:31:33 2021 daemon.info hostapd: wlan0: STA XX:XX:XX:XX:b4:10 IEEE 802.11: associated (aid 10)
Tue Nov 23 17:31:33 2021 daemon.notice hostapd: wlan0: AP-STA-CONNECTED XX:XX:XX:XX:b4:10
Tue Nov 23 17:31:33 2021 daemon.info hostapd: wlan0: STA XX:XX:XX:XX:b4:10 RADIUS: starting accounting session 6E1E892A7CF3AD14
Tue Nov 23 17:31:33 2021 daemon.info hostapd: wlan0: STA XX:XX:XX:XX:b4:10 WPA: pairwise key handshake completed (RSN)
Tue Nov 23 17:31:33 2021 daemon.notice hostapd: wlan0: EAPOL-4WAY-HS-COMPLETED XX:XX:XX:XX:b4:10
Tue Nov 23 17:44:57 2021 daemon.info hostapd: wlan1-1: STA XX:XX:XX:XX:b4:10 IEEE 802.11: associated (aid 4)
Tue Nov 23 17:44:57 2021 daemon.notice hostapd: wlan1-1: AP-STA-CONNECTED XX:XX:XX:XX:b4:10
Tue Nov 23 17:44:57 2021 daemon.notice hostapd: wlan0: Prune association for XX:XX:XX:XX:b4:10
Tue Nov 23 17:44:57 2021 daemon.notice hostapd: wlan0: AP-STA-DISCONNECTED XX:XX:XX:XX:b4:10
Tue Nov 23 17:44:59 2021 daemon.info hostapd: wlan0: STA XX:XX:XX:XX:b4:10 IEEE 802.11: associated (aid 10)
Tue Nov 23 17:44:59 2021 daemon.notice hostapd: wlan0: AP-STA-CONNECTED XX:XX:XX:XX:b4:10
Tue Nov 23 17:44:59 2021 daemon.notice hostapd: wlan1-1: Prune association for XX:XX:XX:XX:b4:10
Tue Nov 23 17:44:59 2021 daemon.notice hostapd: wlan1-1: AP-STA-DISCONNECTED XX:XX:XX:XX:b4:10
Tue Nov 23 17:45:29 2021 daemon.info hostapd: wlan1-1: STA XX:XX:XX:XX:b4:10 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)

Because it only states EAPOL-4WAY-HS-COMPLETED upon the first connection, and not in respect of subsequent connections.

What is the significance of the 'aid 10', etc.?

Came across this:

https://amiyasrivastava.weebly.com/wireless/fast-transition-in-a-nutshell

The Ubiquiti WiFiman seems to be very helpful in monitoring roaming transitions and times.