Enabling 802.11r breaks WPA2 with hostapd (GL.inet fw)

Hi all,

I am running OpenWRT 15.05 (Qualcom SDK) on a GL-inet B1300. When I add the following options:

config wifi-iface 'guest2g'
        option device 'wifi0'
        option network 'guest'
        option mode 'ap'
        option encryption 'psk2'
        option ifname 'ath3'
        option guest '1'
        option ssid 'MyLAN'
        option key 'timesup'
        option mobility_domain '4f57'
        option ieee80211r '1'
        option ft_psk_generate_local '1'
        option ft_over_ds '0'
        option wmm '1'
        option nasid '3B83C400FD66'

It generates a hostapd-ath3.conf that looks like:

root@GL-B1300:/etc/config# cat /var/run/hostapd-ath3.conf
driver=atheros
interface=ath3
#channel=7
logger_syslog=127
logger_syslog_level=1
logger_stdout=127
logger_stdout_level=1
ctrl_interface=/var/run/hostapd-wifi0
wpa_passphrase=timesup
auth_algs=1
wpa=2
wpa_pairwise=CCMP
nas_identifier=3B83C400FD66
ssid=MyLAN
bridge=br-guest
ieee80211w=0
wpa_key_mgmt=WPA-PSK  FT-PSK
mobility_domain=4f57
r0_key_lifetime=10000
reassociation_deadline=1000
pmk_r1_push=1
ft_over_ds=0
r0kh=  000102030405060708090a0b0c0d0e0f
r0kh=  000102030405060708090a0b0c0d0e0f
r1kh=  000102030405060708090a0b0c0d0e0f

However when the wifi comes up - it brings up an unencrypted (open) network and devices can't connect!

I would be grateful for any advice, I am very keen to get 802.11r working!

Upgrade.

Upgrade what? OpenWRT? Unfortunately I need some of the GUI features that the GLinet firmware uses. There are locked into the Qualcomm SDK at 15.05.

I have another AP running 19.07 which has 802.11r configured

If you want to use/are using their fw, ask them for help.

1 Like

I have, with little success. However for this particular problem I am using OpenWRT in LUCI, so I do not think this forum is an inappropriate place to ask.

Almost all routers use openwrt to some extent.
Using that kind of logic, you might as well post your question at tp-link, or netgear.

Since it's their fw, ask them, or upgrade to/install "real" openwrt.

1 Like

Well, except that GLInet supports LUCI fully. I understand if you are not willing to help me, but perhaps let's leave our discussion there in the hope that someone else on this forum might be willing to help?

That's not the point, their fw is a black box to us/this forum, we have no clue of what kind of modification(s) they made, before they released it.

And it's 3.5 years old.

Would you have taken your brand new BMW to a Lexus mechanic? I mean, they're both cars, right?

2 Likes

As indicated the best (and only) place for your questions is the vendor's own support channels. These forums are for vanilla OpenWrt support, not for whatever mutilated and outdated SDKs vendors use.

There's nothing we can do for you here. Talk to your vendor, they have a forum of their own and other support channels too.

I have taken my Skoda superb to a VW garage before. Because it's the same engine and drivetrain with a different body.

And what do you know - it is isn't a GL-inet fw problem after all: Ieee80211r configuration with openwrt LUCI setup

That's a beautiful but crippled analogy. VW and Skoda are almost rebadges of the same hardware. What you are running is an ancient Qualcomm SDK, with a crapload of their own stuff mixed in, and Gl.iNet has thrown LuCI on top of that. So compare it with taking your Skoda Superb to an authorised dealer, with a modern body (LuCI), but with a third party engine loosely based on their own (the SDK) in a configuration the manufacturer (OpenWrt) never delivered it. And the authorised dealer says: 'I'm not familiar with the stuff being pulled there'. That's closer to what you're experiencing.

I'm glad you found a pointer, but that thread you linked to seems to be from someone in the same SDK boat (running 15.05 in 2018...). So yes, it's a Gl.iNet problem, since by now OpenWrt has moved on and this has been fixed for four years.

Anyway - you can replace the hostapd script, it's just a shell script. Or patch yours. But make sure you're not removing other stuff in the process if you replace it. No need to recompile.

1 Like

@Borromini A lesson in why one should avoid reasoning by analogy perhaps.

Many thanks for your pointers, will get to patching the script

Using this config

config wifi-iface
	option device 'wifi0'
	option network 'lan'
	option mode 'ap'
	option blockdfschan '1'
	option ifname 'ath0'
	option athnewind '1'
	option ssid 'MySSID'
	option key 'somehardpassword'
	option disablecoext '0'
	option encryption 'psk2'
	option auth_cache '1'
	option disassoc_low_ack '1'
	option rsn_preauth '1'
	option ieee80211r '1'
	option pmk_r1_push '1'
	option mobility_domain '4f57'
	option ft_over_ds '0'
	option ft_psk_generate_local '1'
	option wmm '1'
	option nasid '5F83C411FD66'

Produces a hostapd.conf

driver=atheros
interface=ath0
#channel=7
logger_syslog=127
logger_syslog_level=1
logger_stdout=127
logger_stdout_level=1
ctrl_interface=/var/run/hostapd-wifi0
wpa_passphrase=somehardpassword
auth_algs=1
wpa=2
wpa_pairwise=CCMP
nas_identifier=5F83C411FD66
ssid=MySSID
bridge=br-lan
rsn_preauth=1
rsn_preauth_interfaces=br-lan
ieee80211w=0
wpa_key_mgmt=WPA-PSK  FT-PSK  
mobility_domain=4f57
r0_key_lifetime=10000
reassociation_deadline=1000
pmk_r1_push=1
ft_over_ds=0

But only because I commented out these three lines (688-690) in the heavily Qualcomm edited :upside_down_face: /lib/wifi/hostapd.sh as the generated rokh had formatting errors or incomplete sections. An what is more, with option ft_psk_generate_local '1' it is possible rokh is not needed

		append "$var" "r0kh=$ap_macaddr $nasid $kh_key_hex" "$N"
		append "$var" "r0kh=$ap2_macaddr $nasid2 $kh_key_hex" "$N"
		append "$var" "r1kh=$ap2_macaddr $ap2_r1_key_holder $kh_key_hex" "$N"

I had a few issues where wifi restarts would wipe parts of the config (especially the nasid) uci commit wireless seemed to improve things some times - although not all of the time.

It seems devices can now connect but I need to find a way to test if fast transition actually works

O.K so the script has no option to detect option ft_psk_generate_local '1' so I crudely added append "$var" "ft_psk_generate_local=1" "$N" at line 688 where the commented out lines are.

However every time I change a wifi setting option nasid '5F83C411FD66' is deleted. I can be bothered to work out what is causing this, so I am just going to use the same hack and add append "$var" "nas_identifier=5F83C411FD66" "$N"

1 Like

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