EKH05 not connecting to HaLow AP

I have an AP (not from MorseMicro) with a HaLow compatible radio MM6108 (specifically expansion/gw16159 – Gateworks). The 924MHz channel is disabled.

I’m trying to do an evaluation of the EKH05 but am running into problems: no connection is established between the two.

Currently I have a DHCP server running on the AP which is handing out addresses in the 10.42.0.100-10.42.0.200 range. Currently the AP I’m trying to stick as close to the EKH05 [users manual] (https://www.mouser.com/datasheet/2/1521/MorseMicro_1252024_UG_MM6108_EKH05-3536537.pdf) as possible but still no avail. I found channel 28 op class 71 to be reliable (916MHz, 8MHz band) and I have two other devices which have the exact same hardware as stations which successfully connect and are given ips through DHCP. Here is my hostapd_s1g.conf and my wpa_supplicant_s1g.conf

DHCP is done with dnsmasq: dnsmasq.conf

Upon connection to power, the EKH05 prints nothing after “this may take some time” even after 10 or 20 minutes.

Does the EKH05 require 924MHz or some extra configuration to connect to an AP?

Thanks

Hi @bstewart

The EKH05 shoudn’t “require” 924 MHz to connect to the AP.

I’m inclined to be suspicious of the region configuration, but given that your hostap is set to US, and the default EKH05 is US - this shouldn’t be causing what you are seeing here. Double check this in configs.c, noting that the guide sets this value to AU, and if you’ve carried this change across it could cause the problem you are seeing.

Failing that, if you run the EKH05 under a debugger, is it actually still running, or is it hung?

We also may want to set up one of your other devices in monitor mode to check it is correctly emitting probe requests. I’ll wait for your confirmation on the region first though.

configs.c does have the default US setting, along with the AP and station.

I don’t believe that the EKH05 is hung, it successfully starts the RTOS and then I lose the ability to dive deeper (abstraction layer) but I could be wrong about it being hung. Is there a way to specifically run the scan tests? I see it as a folder in the organization project but nowhere is it clear on how to actually edit the code that runs on the board.

Below is what I see from my end in the STM32CubeIDE once it gets to the place where it pauses.

Is there a config file where I can specify what I want to happen?
From my point of view it’s really hard to understand the current codebase but that could be attributed to a lack of experience with projects like these; any further instruction would be great, especially a sanity check to make sure the other morsemicro chips on linux systems are functioning properly.

I am running DHCP on the AP, and that may be a cause of unreliability (client has to ifdown and ifup to receive an IP), but I feel that maybe is outside of the scope of establishing a CONNECTION between the two. A scan feature would be great just to make sure the security/ssid/password isn’t at fault (both ap and station are sae ssid:MorseMicro pass:12345678).

DHCP shouldn’t be causing you issues at this stage of the connection initialisation sequence, as you state.

STM32CubeMX should be used to reconfigure the EKH05 example apps during initial bring up/evaluation. If you open your .ioc file and navigate to Software Packs → Select Components, you should be able to select a scan example. Alt - O should open this directly.

especially a sanity check to make sure the other morsemicro chips on linux systems are functioning properly.

If you have a second Linux based device, configure it as a station and connect it to the AP. If they associate and can pass traffic then you can safely rule out the other devices.

Thanks for walking me through that; I was getting that folder but didn’t realize the “generate code” would be different than “build” which was my problem. Still, theres a problem:
On “scan” mode, the EKH05 properly detects my MorseMicro AP w/ sae auth.


Great! This is the sanity check I needed: it confirms my AP is using sae as expected. The MAC addr matches; as per the AP

root@noble-venice:~# iw dev wlan0 info
Interface wlan0
        ifindex 6
        wdev 0x1
        addr 1c:bc:ec:33:56:42
        ssid MorseMicro
        type AP
        wiphy 0
        channel 100 (5500 MHz), width: 160 MHz, center1: 5570 MHz
        txpower 24.00 dBm
        multicast TXQ: ...

Still the problem exists on connecting to it with the demo program, which I actually was able to fix by removing all auth on the AP and setting the “wlan.security” to “open”. Only then does it successfully connect.


Great for a sanity check: I then bridged the networks and successfully accessed the web interface with the camera view and all. Very happy that there’s some progress! But obviously the lack of auth makes this demo pretty useless for a successful evaluation/devkit.

Since it connected without auth with the ssid “MorseMicro”, I left that unchanged in my config. My current config for the EKH05 (that DOES NOT connect; stalls after the This may take some time…) contains:

#include "mmconfig.h"

config_entry_t mm_configs[]={
         /* tcp_client */
        {"iperf.mode", "udp_server"},
        /* IP address of server to connect to when in client mode */
        {"iperf.server", "192.168.1.1"},
        /* Specifies the port to listen on in server mode. */
        {"iperf.port", "5001"},
        /* Duration for client transfers specified either in seconds or bytes. If this is
         * negative, it specifies a time in seconds; if positive, it specifies the number
         * of bytes to transmit. */
        {"iperf.amount", "-10"},

        {"ping.target", "192.168.1.1"},
        {"ping.count", "10"},
        {"ping.interval", "1000"},
        {"ping.size", "56"},
        {"ping.post_ping_delay_ms", "60"},

        /* The following setting is required only for the wnm_sleep example */
        {"wlan.wnm_sleep_duration_ms", "20000"},

        /* The WiFi SSID */
        {"wlan.ssid", "MorseMicro"},
        /* The WiFi password, not required if wlan.security is open */
        {"wlan.password", "test_password"},
        /* The WiFi security to use, valid values are sae, owe and open */
        {"wlan.security", "sae"},
        /* The 2 letter country code to ensure the correct regulatory domain is used */
        {"wlan.country_code","US"},

        /* If true use DHCP, else the static IP configuration will be used */
        {"ip.dhcp_enabled", "true"},

        /* These settings are ignored if DHCP is used, but mandatory if using static IP */
        {"ip.ip_addr", "192.168.1.2"},
        {"ip.netmask", "255.255.255.0"},
        {"ip.gateway", "192.168.1.1"},

        /* These settings are for IPv6, ip6.ip_addr is only required if ip6.autoconfig is
         * false */
        {"ip6.autoconfig", "true"},
       /* commented settings.. */
       //array terminator
       {NULL, NULL}

The only thing changed from the base config is the password, I tried a few but ensured right now that the AP is actually on MorseMicro:test_password, and the other station successfully connects to it (and is assigned a DHCP ip)

wpa_supplicant_s1g.conf (works nicely)

network={
        ssid="MorseMicro"
        key_mgmt=SAE
        psk="test_password"
}

Just to confirm, heres the output from the EKH05

Very strange. Since I am able to connect with sae to the AP I feel like it rules out the problem being auth on the AP.

It would be helpful to see your hostapd configuration, and debug logs while the EKH05 is attempting to authenticate/associated (pass -dd to the hostapd_s1g command on the AP).

It looks like something might be failing in the authentication or eapol exchange for the EKH05. My suspicion is that protected management frames isn’t being enabled on the AP, which the embedded microcontroller stack requires to be enabled (unless open auth is used).

For protected management frames, please set ieee80211w=2 in your hostapd configuration.

Additionally, you may be running into a misalignment in authentication methods, please ensure sae_pwe is set to 1 or 2 in your hostapd config.