[WIFI] 802.11r/FT: fast transition not working for 2nd SSID

Hi guys,

it seems I have run into a weird problem with 802.11r Fast Transition. It seems to work only for 1 of my 2 WIFI networks.

Here's the details:
I have 3 WIFI access points (2x Netgear WNDR4300, 1x Netgear WNDR3700v2). Each of those APs has 2 radios - one in 2.4 GHz and another one in 5 GHz band. For each of the 2 radios I have defined 2 SSIDs: Home-net and Guest-net.
So each AP has a total of 4 WIFI interfaces:

  • Home-net @ 2.4GHz
  • Home-net @ 5GHz
  • Guest-net @ 2.4GHz
  • Guest-net @ 5GHz

All the WIFI interfaces of the same SSID are bridged together into a separate VLAN.

802.11r is configured identically on all 4 WIFI interfaces. I'm using a very simple FT config that generates the keys locally based on the pre-shared key and I let most of the required settings to be generated automatically.
An excerpt of the actual wireless and network configuration file is attached at the end.

Now, my problem is that fast-transitioning works for the Home-net, but not for the Guest-net.
Home-net roaming is really working great and as expected. I can fast-transition between the radio cells of the same AP (2.4GHz <-> 5GHz) as well as fast-transition between the cells of the different APs.

Fast-transitioning of the Guest-net on the other hand is however not working at all. Even though it is essentially using the same configuration as the Home-net.
I already tried to provide explicit values for some of the relevant 802.11r settings like NASID and Mobility-Domain, but that does not seem to make any difference.
Is there maybe a bug or known limitation that makes 802.11r work with just the first WIFI interface of a radio?

--

wireless


config wifi-device 'radio0'
	option type 'mac80211'
	option hwmode '11g'
	option path 'platform/ar934x_wmac'
	option country 'DE'
	option legacy_rates '0'
	option htmode 'HT20'
	option log_level '1'
	option channel '11'
	option txpower '17'

config wifi-device 'radio1'
	option type 'mac80211'
	option hwmode '11a'
	option path 'pci0000:00/0000:00:00.0'
	option country 'DE'
	option legacy_rates '0'
	option htmode 'HT40'
	option log_level '1'
	option channel '36'    

## home-net 2.4 GHz
config wifi-iface 'default_radio0'
	option device 'radio0'
	option mode 'ap'
	option network 'WIFI-HOME'
	option encryption 'psk2+ccmp'
	option key '***redacted***'
	option ssid 'home-net'
	option macfilter 'allow'
	list maclist '***redacted***'
	option wpa_disable_eapol_key_retries '1'
	option ieee80211r '1'
	option ft_psk_generate_local '1'
	option ft_over_ds '0'
	option max_inactivity '30'

## home-net 5 GHz
config wifi-iface 'default_radio1'
	option device 'radio1'
	option mode 'ap'
	option network 'WIFI-HOME'
	option encryption 'psk2+ccmp'
	option key '***redacted***'
	option ssid 'home-net'
	option macfilter 'allow'
	list maclist '***redacted***'
	option wpa_disable_eapol_key_retries '1'
	option ieee80211r '1'
	option ft_psk_generate_local '1'
	option ft_over_ds '0'
	option max_inactivity '30'

## guest-net 2.4 GHz
config wifi-iface 'wifinet2'
	option device 'radio0'
	option mode 'ap'
	option network 'WIFI-GUEST'
	option encryption 'psk2+ccmp'
	option key '***redacted***'
	option ssid 'guest-net'
	option wpa_disable_eapol_key_retries '1'
	option ieee80211r '1'
	option ft_psk_generate_local '1'
	option ft_over_ds '0'
	option max_inactivity '30'

## guest-net 5 GHz
config wifi-iface 'wifinet3'
	option device 'radio1'
	option mode 'ap'
	option network 'WIFI-GUEST'
	option encryption 'psk2+ccmp'
	option key '***redacted***'
	option ssid 'guest-net'
	option wpa_disable_eapol_key_retries '1'
	option ieee80211r '1'
	option ft_psk_generate_local '1'
	option ft_over_ds '0'
	option max_inactivity '30'

network

config switch
	option name 'switch0'
	option reset '1'
	option enable_vlan '1'

## trunk
config switch_vlan
	option device 'switch0'
	option vlan '1'
	option vid '1'
	option ports '0t 1 2 3'



## home-net VLAN
config switch_vlan
	option device 'switch0'
	option vlan '2'
	option vid '10'
	option ports '0t 1t'

config interface 'WIFI-HOME'
	option ifname 'eth0.10'
	option type 'bridge'
	option proto 'static'
	option ipaddr '192.168.2.254'
	option netmask '255.255.255.0'
	option igmp_snooping '1'
	option ip6ifaceid '::192:168:2:254'



## guest-net VLAN
config switch_vlan
	option device 'switch0'
	option vlan '3'
	option ports '0t 1t'
	option vid '20'

config interface 'WIFI-GUEST'
	option ifname 'eth0.20'
	option type 'bridge'
	option proto 'static'
	option ipaddr '172.22.25.254'
	option netmask '255.255.255.0'
	option igmp_snooping '1'


Aww.. is nobody with 2 SSIDs able to test this?

It's quite easy actually. You just need to enable the debug log of hostapd and then you can see the corresponding FT messages in the system log.

root@OpenWrt:~# uci set wireless.radio0.log_level=1
root@OpenWrt:~# uci set wireless.radio1.log_level=1
root@OpenWrt:~# uci commit wireless
root@OpenWrt:~# wifi up
root@OpenWrt:~# logread -f | grep 'FT authentication'

If fast transitioning between the cells is working, you'll see a message skipping the 4-way handshake for your device:

daemon.debug hostapd: wlanX: STA [mac-of-device] WPA: FT authentication already completed - do not start 4-way handshake

I just did another test: I deleted the 2 Home-net interfaces.
Once deleted fast transitioning via the Guest-net interfaces started to work. I tested it by roaming between the 2.4 GHz and 5 GHz networks of the same AP.

I guess I have to create a bug report...

1 Like

FTR: The bug entry is at https://bugs.openwrt.org/index.php?do=details&task_id=3474

I have tried the same half a year ago, but I do not have a guest vlan that is shared between the 2 access points.

So I thought in order to get this working I would need a

  • guest vlan shared between both APs
  • common dhcp in this guest vlan

That is why I did not continue the testing there.
On the other hand one might anyhow consider isolating the clients in guest wifi, and I want to be able to switch the APs on and off independently. So the dhcp would need to be separated from both, but in guest vlan.

That was too complicated to achieve for me.
So you have set up the guest vlan with a common dhcp ?

Another thought:
You are using the implicit method ft_psk_generate_local...

Have you used different mobility domains for the different wifis?
option mobility_domain '1111' vs
option mobility_domain '2222' ?

Hi Stefan. Thanks for your feedback.

From what I understand, I believe the network part of the configuration is not really relevant.
The problem seems to me to be in the "wireless section" or more specifically a problem of the hostapd service. It occurs, when multiple SSIDs are used with the physical wireless hardware. It seems to happen in a situation, when you have a single 2.4 GHz and/or a single 5 GHz antenna, but you tell hostapd to run 2 or more cells via those antennas. Then hostapd needs to apply a sort of "virtualization" and share the one physical antenna with all the configured cells.
At this point there seems to be either a short coming or a confusion in hostapd, when it comes to the 802.11r implementation. It seems like there is something in it that produces a behavior like this pseudo code

List allSSIDs = ... // get all configured SSIDs
if (allSSIDs > 1) {
   logger.error("oops.. multiple SSIDs not supported - fallback to first SSID")
}
selected = allSSIDs[0] // we always use the first SSID

Based on my tests the problematic behvior is deep inside hostapd and not "accessible" via OpenWRT board tools. It is not configurable. Or in other words. The wireless configuration I use and have posted ITT is totally fine.
In fact I can make roaming work just fine with any one of my SSIDs! I just have to somehow place the SSID I want to have working into the first spot of the list. The configuration of my SSIDs are fine as they are. I can exchange them randomly.
The problem is the limitation to one SSID. It seems I cannot have both/all SSIDs working with FT simultaneously... :frowning:

To answer your specific questions:

  • The network part is not relevant.
    Yes, I have a guest subnet with its own DHCP and it spans all APs via VLAN. But that is not important. You don't need to create VLANs. For the sake of testing I guess you can bridge the WIFI interfaces into the same physical network (even though that is nonsensical from an isolation point of view).
  • Yes, I have tried to not rely on the generated FT configuration. I tested all of it. I even created the External R0/R1 Key Holder lists manually. It's all good. The configurations do work, if they are "the chosen one" at slot #1.
2 Likes