I’ve been trying Passpoint configuration on two HaLowLink 2 (JP), one for AP and the other for client. I tested WPA3 Enterprise configuration earlier and it worked.
I’ve added Passpoint configuration (hs20_ and iw_ options) to /etc/config/wireless on the AP. It seems that they are successfully added to hostapd-phy1-wlan0.conf and working well.
On the client side, however, the authentication by WPA3 Enterprise fails to start despite the successful ANQP.
I think there are some parameter mismatch as I see “freq=5200”.
I suspect operator_class and s1g_prim_chwidth parameters.
What are the correct values for 4MHz-width, channel 36 in Japan?
1788926906.270490: Successfully initialized wpa_supplicant
1788926906.288105: rfkill: Cannot open RFKILL control device
1788926906.324116: morse_sta_configure_channelization: channelization scheme 3 country JP
Here’s more detailed log lines. Just after the INTERWORKING-SELECTED, the association fails.
Interworking: Considering BSS 50:2e:91:d2:c9:0e for connection
wlan0: Interworking: Highest roaming consortium matching credential priority 0 sp_priority 0
wlan0: Interworking: Connect with 50:2e:91:d2:c9:0e based on roaming consortium match
wlan0: Try to find BSS matching pre-selected network id=0
wlan0: 0: 50:2e:91:d2:c9:0e ssid=‘Cyber-HaLow2’ wpa_ie_len=0 rsn_ie_len=20 caps=0x431 level=-24 chan=15
wlan0: skip RSN IE - key mgmt mismatch
wlan0: reject due to mismatch with WPA/WPA2
I’ve learnt that Morse Micro’s software translates the frequencies to 2.4/5GHz conventions. If so, the Operating Class might not be the cause of this problem. Assuming that the Interworking is working from the observations.
I would say the frequency is not your issue here. As you’ve noticed our current driver pretends to be an 802.11ac device so as to be a little more portable to Linux. It’s only recently that upstream Linux has had some native S1G love.
To your issue. I’ve dug up an old wpa_supplicant config for the HaLow radio from when we were experimenting with OpenRoaming. See below:
The key difference I can see is that mine has set pmf=1, which could explain the failure to parse ANQP response here - the client isn’t treating them as protected frames.
Strictly speaking to be Wi-Fi HaLow, hash to element should be used (sae_pwe=1).
Now I can see Passpoint working after adding pmf=1.
It was a pitfall that the AP is configured to be compatible with WPA3 but the client requires explicit enforcement.
wlan0: INTERWORKING-SELECTED 50:2e:91:d2:c9:0e
wlan0: SME: Trying to authenticate with 50:2e:91:d2:c9:0e (SSID=‘Cyber-HaLow2’ chan=15)
wlan0: Trying to associate with 50:2e:91:d2:c9:0e (SSID=‘Cyber-HaLow2’ chan=15)
wlan0: Associated with 50:2e:91:d2:c9:0e
…
And, thanks for the clarification regarding the special frequency handling.
I’m using the release version of HaLowLink 2: ver. 2.11.13
I’ll try the ver.3 in the GitHub repository next week.