Hi, I’m having a problem with this setup and likely need help creating a proper WPA3 wpa_supplicant_s1g conf file. I am getting AUTH TIMEOUT errors specifically when trying to connect a GW16159 STA to a HaLowLink 1 AP with WPA3 SAE.
What works:
GW16159 STA ↔ GW16159 AP
GW16159 MESH ↔ GW16159 MESH
EKH05 STA ↔ GW16159 AP (WPA3)
EKH05 STA ↔ HaLowLink 1 AP
The HaLowLink appears when I scan for APs on the GW16159 (attached log)
The output from wpa_supplicant_s1g seems to get to the authentication phase but times out, specifically between lines 348 and 379. The log also contains the morse_cli version and conf file. I couldn’t find any pre-made examples of WPA3 S1G configuration, and all the other ones I’ve tried have failed due to parsing or the same AUTH_TIMED_OUT error.
Another interesting thing to note is after this error, iw dev wlan0 scan returns nothing, until I reload the kernel module and ifconfig wlan0 up.
Any sanity checks and default configuration would be greatly appreciated. Thank you
There is an example (and minimal) set of both hostap and wpa_supplicant configurations towards the end of the Linux Porting Guide - which you’ve also reminded me to chase down the update. You can also extract configs off HaLowLink1s configured in ways you desire by looking at /var/run/wpa_supplicant-wlan0.conf and /var/run/hostapd-phy<n>.conf.
Still going through the error log, but the HaLowLink1 will be set as sae_pwe=1. With the supplicant config set as sae_pwe=2, maybe it’s trying hunting and pecking? Wi-Fi HaLow certification allows Hash-to-Element only. Worth trying sae_pwe=1.
Will let you know if we spot anything else in the log.
I’ve read through the Linux Porting Guide and brought over your minimal conf file and startup command. Still getting AUTH_TIMED_OUT and then no longer finding the network (log includes when I ^C and manually stop the process)
Here’s a few things that I’ve noted:
I was using the wrong ctrl_interface, so I changed it to be s1g
Both the HaLowLink and my GW16159 (Silex SX-SDMAH module) have the same FW and HW version, but my HaLowLink Morse_cli version is rel_1_12_4_2024_Jun_11 while my SBC is Morse_cli version rel_1_12_5_2024_Jul_25-4-g3541610.
Here’s the log from today which includes my lsmod, conf, morse_cli version, and the wpa_supplicant_s1g. If you think that there might be a kernel/firmware problem, let me know and I can send any other system configuration.
Also: my HaLowLink has no wpa_supplicant configuration files in /var/run, only an empty directory. I’ll now try and test AP/STA between two GW16159 boards (instead of using the HaLowLink as the AP) to try and narrow down this issue. Thanks again for the help.
Blake
EDIT: Between two GW16159s running on identical setups, one as the STA I’ve been trying to connect and another as a WPA3 AP, I’ve successfully made a connection. It seems that the security is the same, and here’s a link to an iw scan that shows both APs. Both seem to be on CCMP and SAE.
The morse_cli version is an artefact of the initial effort to Open Source software which was previously closed source. Not pretty, but shouldn’t be a contributing factor here.
Sorry I should have been clearer. If your HaLowLink1 is configured as an AP, it will only have a /var/run/hostap-phy<N>.conf file. If you put it into a client mode, it will build a supplicant config. Curious to know if a HaLowLink1 in client mode connects to the GW16159 AP.
So there are two things that stand out to me here:
SAE auth timeout - which I would have expected to be the sae_pwe setting. Moving on..
Signal strength from the HaLow AP is -11dBm. This is quite a hot signal (though anecdotally things should still function here), moving the devices another few meters away or angling the HaLowLink1 antenna ~45 degrees, might add enough attenuation if an SAE frame is corrupted in transit.
It might be helpful to extract AP logs from the HaLowLink1 if the above doesn’t work. ssh into the HL1 and add option log_level '0' to the wifi-device of option type morse in /etc/config/wireless. Then service network restart to restart the AP. This should output more hostap logging to the HL1 syslog which you can extract with logread -l -f -e hostapd_s1g. Hopefully this tells us why the AP is rejecting the station.
Failing that - putting a third device in monitor mode to inspect the packets in flight might be required as well. There’s some instructions for putting Morse Micro devices into a sniffer mode in APPNOTE-36. This should work for your GW-16159 devices as well if you follow the CLI configuration.
@ajudge Turns out the problem was relatively expected behavior; as per the GW16159 documentation 924MHz is disabled in mm6108 firmware due to noise exceeding specification
Upon changing the HaLowLink AP frequency to 916MHz the board connects nicely.
