Trying to connect Lilygo T-Halow client to MM8108-EKH19 AP

Hardware
1

They are having problems connecting, they seem to see each other but Claude Code thinks packets are getting dropped at Morse module level as it reloads the baked in AU country code, also it’s very troubled by the country_code=ZZ.

I have GB in the UI and matched MHz. No password.

Is there a way to get them to connect?

MM8108-EKH19 AP

wireless.radio2=wifi-device
wireless.radio2.type=‘morse’
wireless.radio2.path=‘platform/11200000.usb/usb1/1-1/1-1:1.0’
wireless.radio2.band=‘s1g’
wireless.radio2.hwmode=‘11ah’
wireless.radio2.reconf=‘0’
wireless.radio2.country=‘GB’
wireless.radio2.channel=‘auto’
wireless.radio2.s1g_chanbw=‘2’
wireless.radio2.s1g_capab=‘[SHORT-GI-NONE]’
wireless.radio2.ampdu=‘0’
wireless.radio2.disabled=‘0’
wireless.radio2.s1g_prim_chwidth=‘2’
wireless.default_radio2=wifi-iface
wireless.default_radio2.mode=‘ap’
wireless.default_radio2.device=‘radio2’
wireless.default_radio2.network=‘ahwlan’
wireless.default_radio2.ssid=‘MT’
wireless.default_radio2.encryption=‘none’
wireless.default_radio2.wnm_sleep_mode=‘0’

morse reattach_hw=0 country=GB bcf=morse/bcf_mf15457.bin enable_sgi_rc=0 macaddr_suffix=89:3b:fe enable_ps=0
root@M:~# modprobe morse country=GB bcf=morse/bcf_mf15457.bin reattach_hw=0 enable_sgi_rc=0 macaddr_suffix=89
:3b:fe enable_ps=0

root@M:~# cat /sys/module/morse/parameters/country
AU

root@M:~# hostapd_cli_s1g -p /var/run/hostapd_s1g -i wlan0 status | grep country
country_code=ZZ

Lilygo T-Halow client

st to 0c:bf:74:00:33:47, ssid=MT (freq:8660)
.[0m[1927136].[31msend assoc request to 0c:bf:74:00:33:47, ssid=MT (freq:8660)
.[0m[1927737].[31msend assoc request to 0c:bf:74:00:33:47, ssid=MT (freq:8660)
.[0m[1927963]
LMAC STATUS:
local: c6:e8:35:7d:8f:18 AID= 0
freq= 866.0 bw=2 chn=3 bgr=-60 iq=0:50:-1:0 dc=0:0(1:21) tx=*5 dly=72:0:0 sif:rsp=0:0(0)
chn: 866.0
bgr: -60
buf: free=78 tq=0 sq=0 ac=0:0:0:0 agg=0:0:0:0 statq=0 rxq=0:0 skb=0:0 rxb=120K
irq: ac=170 bkn=0 bo(rts:frm)=0:0:0:0:133 to(rts:frm)=0:132 rx=58
tx : cnt=133 dly=0:0ms mcast(bw:mcs)=2:0 agg=1(5554,170:0) data=15KB(0kbps) dur=101ms cca=2288 per=99% est_rate=0kbps fail=132 drop=19
rx : cnt=58 bus=1ms cts_bm=0:0 pks=58 data=3KB(4kbps) dur= 46ms err(phy:fcs)=0:0 ecode=0x0 rssie= 0:0 cache_rxq= 0:0
dbg: dtmd=0:0:0 stamap=0x0 sleepmap=0x0 flag=0x0 rxdp=0 kerr=0 mic=0 lerr=0 kick=0 csc=0 rst=12 ovf=0 nob=0 tsnr=0 rssi=0 rxdut=0% txp=0 rxg=5
cca: 4s st12= 53:0 mid1224= 30:7718:0:0 ed1224= 46:46:0:0 ch_bz= 6
chip-temperature:43, vcc:3.31, vdd13b:1.30, vdd13c:1.30
sta_list: no sta
[1928282].[31msend assoc request to 0c:bf:74:00:33:47, ssid=MT (freq:8660)
.[0m[1928703].[31msend assoc request to 0c:bf:74:00:33:47, ssid=MT (freq:8660)

.[0m+WNBCFG (5) OPEN
role:sta, bss_bw:2, encrypt:0, forward:1, key_set:0, mkey_set:0, join_group:0, bssid_set:0
freq_range:0~0
chan_list: 8660,
ssid:MT, r_ssid:, addr:c6:e8:35:7d:8f:18
max_sta:8, tx_mcs:255, acs_enable:1, acs_tmo:0, tx_bw:2
country_region:, tx_power:20, pri_chan:3
psconnect_period:60, psconnect_roundup:4
wkio_mode:0, psmode:0, wait_psmode:0, auto_chsw:0, acktmo:0
bss_max_idle:300, beacon_int:500, dtim_period:2
group_aid:0, agg_cnt:0, aplost_time:10, roam_rssi_th:-60, roam_int:5, roam_rssidiff:12
dhcpc_en:0, dhcp_host:, ack_tmo:0, reassoc_wkhost:0, mcast_filter:0
auto_role:0, roaming:0, dupfilter:1, pa_pwrctrl_dis:0, pair_autostop:0, supper_pwr:1, mac_set:0
not_auto_save:0, dcdc13:0, auto_pair:0, heartbeat_int:500, auto_sleep_time:0, wkup_io:0, wkio_edge:0
ap_psmode:0, dis_1v1_m2u:0, psconnect_dis:0, ap_hide:0, roaming_samefreq:0, max_txcnt:7, repeater_level:1
mcast_txmcs:0, mcast_txbw:0, mcast_clearch:0, mcast_dupcnt:0
wkup_host_reason:2,3,4,9,11,8,7,12,14,
[1930947].[31msend assoc request to 0c:bf:74:00:33:47, ssid=MT (freq:8660)

2

Is this a fundamental cross-vendor interoperability issue?

Morse dot11ah driver silently drops 802.11ah assoc frames that don’t contain Morse-specific S1G capability elements.

  • Morse firmware is GB, correct channels, correct BW
  • TaiXin is hearing beacons fine
  • But Morse driver never ACKs a single TaiXin frame — per=100%
  • hostapd_s1g never logs even one byte from c6:e8:35

Command timeouts in dmesg — the firmware is failing commands:Command morse_cmd_vendor 200e:3c1 timed out Command 0x000e:03d0 error -32757

The firmware is running correctly now — mm8108b2-rl.bin, SW version 1.16.4, GB regulatory, correct channels. The AP is up. But look at this from the debug output:
enable_mm_vendor_ie: Y

If enable_mm_vendor_ie finally shows N and the TaiXin still doesn’t associate, the issue is an 802.11ah S1G capability element incompatibility between Morse and TaiXin at the MAC layer — which would require either a Morse firmware update that relaxes the requirement, or a TaiXin firmware update that adds the required IEs.

3

Hi @Stanley

Is this a fundamental cross-vendor interoperability issue?

Most likely, Wi-Fi HaLow is a maturing protocol after all. Products wishing to validate interoperability will run against Wi-Fi Alliance test infrastructure. We pass these tests.

Because we pass, I would be suspicious of the Lilygo, but there is always the opportunity for an edge case.

A sniffer capture will help tell us more about what is happening here. If you have another Morse Micro device, have a read of https://www.morsemicro.com/resources/appnotes/MM_APPNOTE-36_How_to_do_a_Sniffer_Capture.pdf. For Europe, you will want to pay attention to the CLI configuration, as the channel might change - so you will need to configure the sniffer manually as it changes.

4

Not offering a ton of information here @Stanley but I did run in to a similar issue when trying to interoperate using the Seeedstudio wm6108 and an Alfa Halow-U. When I heard from Alfa they stated similar to what @ajudge said where Halow is evolving and when Alfa setup their solutions it was at a different phase of Halow development and this means things may not work across ecosystems. I’ve since then stuck to all Morse Micro chips :wink:

No real answers for you but hopefully you feel less crazy.

5

I tested Seeed WiFi Halow module also, it works from my end. But you need to choose correct bcf files for Quectel Halow module. From my test, Morse micro chips has good compatibility across MM6108, and MM8108. The only compatibility issue is for EU, MM8108 2MHz is not supported by MM6108. Lilygo T-Halow is a different case, it uses Xiamen Taixin AH chip, it’s quite different stack, from my experience, mostly it’s runing on Mac layer, and there is a RJ45 socket to convert to Ethernet packet. For WiFi halow part, they have their own packet definition, if you want to make them work together, I guess you need implement the adaptation layer.