Passpoint configuration for Wi-Fi HaLow

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

1788926906.324181: morse_set_channelization_scheme: scheme=3

1788926907.167919: wlan0: Starting ANQP fetch for 50:2e:91:d2:c9:0e (HESSID 50:2e:91:d2:c9:0e)
1788926907.168359: wlan0: GAS-QUERY-START addr=50:2e:91:d2:c9:0e dialog_token=230 freq=5200
1788926907.179354: wlan0: GAS-QUERY-DONE addr=50:2e:91:d2:c9:0e dialog_token=230 freq=5200 status_code=0 result=SUCCESS
1788926907.180004: wlan0: RX-ANQP 50:2e:91:d2:c9:0e ANQP Capability list
1788926907.180174: wlan0: RX-HS20-ANQP 50:2e:91:d2:c9:0e HS Capability List
1788926907.180260: wlan0: ANQP-QUERY-DONE addr=50:2e:91:d2:c9:0e result=SUCCESS
1788926907.180347: wlan0: ANQP fetch completed
1788926907.180488: wlan0: INTERWORKING-AP 50:2e:91:d2:c9:0e type=unknown id=0 priority=0 sp_priority=0
1788926907.180584: wlan0: INTERWORKING-SELECTED 50:2e:91:d2:c9:0e
1788926907.182318: wlan0: Starting ANQP fetch for 50:2e:91:d2:c9:0e (HESSID 50:2e:91:d2:c9:0e)
1788926907.182952: wlan0: GAS-QUERY-START addr=50:2e:91:d2:c9:0e dialog_token=241 freq=5200
1788926907.208659: wlan0: GAS-QUERY-DONE addr=50:2e:91:d2:c9:0e dialog_token=241 freq=5200 status_code=0 result=SUCCESS
1788926907.209304: wlan0: RX-ANQP 50:2e:91:d2:c9:0e ANQP Capability list
1788926907.209793: wlan0: RX-HS20-ANQP 50:2e:91:d2:c9:0e HS Capability List
1788926907.210100: wlan0: ANQP-QUERY-DONE addr=50:2e:91:d2:c9:0e result=SUCCESS
1788926907.210180: wlan0: ANQP fetch completed
1788926907.210323: wlan0: INTERWORKING-AP 50:2e:91:d2:c9:0e type=unknown id=0 priority=0 sp_priority=0
1788926907.210420: wlan0: INTERWORKING-SELECTED 50:2e:91:d2:c9:0e
1788926907.947510: wlan0: Starting ANQP fetch for 50:2e:91:d2:c9:0e (HESSID 50:2e:91:d2:c9:0e)

Tested command line was:
/usr/sbin/wpa_supplicant_s1g -t -D nl80211 -i wlan0 -c /tmp/wpa_supplicant.conf

Here’s an example of wpa_supplicant.conf for Passpoint testing.

country=JP
ctrl_interface=/var/run/wpa_supplicant_s1g
sae_pwe=1
interworking=1
hs20=1
auto_interworking=1

cred={
roaming_consortiums=“5a03ba0000”
ca_cert=“/etc/ssl/certs/ca-certificates.crt”
domain_suffix_match=“idp.example.com
username="userID@idp.example.com"
password=“userPass”
phase2=“auth=PAP”
eap=TTLS
}

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.

Hey @hgot07

Have you had a look at GitHub - MorseMicro/openroaming: An OpenWrt package feed for easing the deployment of OpenRoaming device configuration. · GitHub? This was a previous demo used to add OpenRoaming to a HaLowLink1 (both client and AP sides). It should carry over to the HaLowLink2 relatively easily.

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:

country=AU
ctrl_interface=/var/run/wpa_supplicant_s1g
pmf=1


interworking=1
hs20=1
auto_interworking=1


cred={
        username="anon@idp.openroamingconnect.org"
        password="....."
        phase2="auth=MSCHAPV2"
        ca_cert="/etc/ssl/certs/ca-certificates.crt"
        eap=TTLS
        roaming_consortiums="5A03BA0000"
        realm="idp.openroamingconnect.org"
}

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).

Many thanks!

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.