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.

6

Adding controlled measurements from a similar LilyGO/HT-HC33 setup. These are observations only, not a proposed root cause.

Hardware / firmware

  • Healthy replacement Heltec HT-HC33: MM6108, exact Heltec bcf_mf08551.mbin, morselib 2.12.3, radio firmware 1.17.9.
  • LilyGO T-Halow VER1: TX-AH-R900PNR/TXW830x, WNB v1.6.4.3-39706.
  • Initial comparison: open security, 1 MHz, 914.5 MHz.

Controls and results

  • The healthy MM6108 receives a Morse AP on every focused scan at about -25 dBm, so its RX path and BCF are known good.
  • With Taixin as AP, six successful one-second directed scans returned zero results. Final Morse counters were scans=6, hw_restarts=0, rxq_hwm=0, and mgmtq_hwm=0, with no RX drops or allocation/read failures.
  • The result remained zero with WNB builds 28977 and 39706 and at 1/2/4/8 MHz. Taixin multicast/beacon-class TX was verified at 1 MHz, MCS0, no duplication; disabling traveling pilots also made no difference.
  • In the reverse direction, Taixin receives the Morse AP and sends directed requests to the correct BSSID, but the Morse AP produces no authentication/association callback and its host RX high-water marks remain zero.

No over-the-air sniffer capture has been made yet.

We found that the newer Taixin v2.4 FMAC source has separate standard AP/STA and private WNBAP/WNBSTA modes. A standard-AP beacon test is prepared but not flashed while we wait for Taixin’s supported migration/recovery procedure: Supported WNB v1.6.4.3-39706 to FMAC v2.4.1.5 migration and recovery · Issue #1 · Taixin-Semiconductor/TXW8301_FMAC · GitHub

Questions for the Morse side:

  1. In morselib 2.12.3 / radio firmware 1.17.9, are rxq_hwm and mgmtq_hwm downstream of radio-firmware PHY/FCS/management filtering? Which lower-level counter or diagnostic can distinguish “no PPDU detected” from “frame detected but rejected before host UMAC”?
  2. Is any TXW8301 interoperability issue known for this firmware generation?
  3. Can an ESP32-hosted MM6108/HT-HC33 produce a useful monitor-mode capture, or is Linux-based Morse evaluation hardware required for the pcap requested above?
7

Update: I have now flashed the Taixin EVB/standalone firmware (project type 5) and repeated both directions. Short version: switching from Taixin’s proprietary WNB stack to their standard AP/STA implementation changed nothing.

Firmware under test - LilyGO T-Halow VER1 (TX-AH-R900PNR), official archive from Taixin’s download centre:

txw8301_v2.4.1.5-43933_2026.7.24_default-SDIO-SLEEP.bin
372240 bytes, SHA-256 3207913D54EA8B952F8BF7B4565BC6BD21C1A09340C096D28C1D24F84F173FA4
module reports: +VERSION: v2.4.1.5-43933, app:0

Configured as a standard AP (AT+WIFIMODE=ap, i.e. not the private wnbap mode), open (AT+ENCRYPT=0), 1 MHz, 914.5 MHz.

Peer unchanged: healthy Heltec HT-HC33, MM6108, Heltec-extracted bcf_mf08551.mbin, morselib 2.12.3, radio firmware 1.17.9.

Results

  • Taixin standard AP → Morse: six directed 1 s scans, zero results each. Final counters scans=6, hw_restarts=0, rxq_drop=0, rx_alloc_fail=0, rx_read_fail=0, rxq_hwm=0, mgmtq_hwm=0.

  • Morse SoftAP (open, S1G ch 25 / 914.5 MHz, PMF disabled) → Taixin standard STA: the Taixin resolves the SSID and the correct BSSID and sends authentication, then gives up:

    ieee80211_sta_select_bss:24::by SSID find halowtest [00:00:04:e1:52:5c] at channel 1
    ieee80211_sta_assoc_timeout:53::connect to ap 00:00:04:e1:52:5c timeout, disable it!

Throughout those attempts the Morse AP produced no sta_status callback and its RX high-water marks stayed at 0.

Why I think this sits below the MAC

rxq_hwm and mgmtq_hwm are host-side queue marks. A mismatch in security, capabilities, information elements or BSSID should still produce received frames and move them. Zero in every run suggests nothing was ever delivered from the radio firmware, which points at PPDU/PHY rather than MAC policy. That is consistent with the fact that no combination of SSID, security, bandwidth (1/2/4/8 MHz), channel or mode has moved it across WNB 28977, WNB 39706 and now standard EVB 43933.

The failure is also strictly one-way: the Taixin demodulates Morse well enough to resolve SSID and BSSID, while no MM6108 here has ever queued a single Taixin frame.

Ruled out on the Taixin side (read-only queries):

+RADIO_ONOFF:radio: TX/RX ON      +ANT_DUAL:dual ant disable
+ANT_DEF:ant default= 0           +ANT_AUTO:tx ant fixed
+TXPOWER:20                       +TX_ATTN:tx atten= 1.1 dB
+LO_FREQ:LO freq= 914500 KHz      +XO_CS:XO CS val= 0xc

Questions

  1. Can MM6108 radio firmware discard a PPDU (preamble/format/FCS) before anything increments a host-visible counter? Is there any counter, log level or debug hook in morselib 2.12.3 / fw 1.17.9 that distinguishes “no PPDU detected” from “detected but rejected”?
  2. Is there a supported way to get a monitor/promiscuous capture from an ESP32-hosted MM6108? mmwlan_register_rx_pkt_ext_cb looks like 802.3 data after association, and mmwlan_ate_execute_command is documented as opaque, so I assume Linux-based Morse hardware is required - but I would like to confirm before buying anything.
  3. If I capture the Taixin beacon with a 915 MHz SDR, would that be useful to you, and is there a capture format or spec you would prefer?

Raw serial logs for both directions are available if helpful.

8

If you have a Morse Micro Linux based evaluation kit you could look at the stats which are accessed with morse_cli -i wlan0 stats. I don’t have a particular stat in mind, and would need to check tomorrow to see if we have something which can help you here. But feel free to take a look before I get there!

We don’t have any official support for monitor mode on our microcontroller based libraries. Best option is to get a Linux based evaluation kit or HaLowLink device.

I would prefer a wireshark capture (pcap) from one of our devices in monitor mode. Here’s an application note to help: https://www.morsemicro.com/resources/appnotes/MM_APPNOTE-36_How_to_do_a_Sniffer_Capture.pdf

9

Thanks @ajudge - that settles the tooling question. I’ll stop trying to squeeze a capture out of the ESP32-hosted MM6108.

Important correction on my side, and a recommendation for anyone investigating this silicon.

Taixin ships two firmware families for the TXW8301, and they are not interchangeable. The version string is SDK_Ver[x.x.x].Project_Type:

  • project type 3 = WNB, their proprietary Wireless Network Bridge stack. This is what almost every field device runs - the AliExpress/Amazon HaLow “bridge pairs”, and the stock LilyGO T-Halow.
  • project type 5 = EVB / standalone. This is where the standard AP/STA modes live.

So interop conclusions drawn from type-3 firmware do not necessarily apply to type 5, and vice versa. My results above are on type 5 (2.4.1.5-43933, standard AT+WIFIMODE=ap/sta), which as far as I can tell has not been reported against Morse hardware before. If Morse Micro ever does look at TXW8301 interop, I’d suggest testing against type 5 rather than the WNB builds most people have.

Third-party sniffer evidence that likely answers my first question.

Craig Peacock has published Wireshark captures of a TXW8301 (T-Halow-RJ45) on type 3 firmware, in its “standard” AP mode:

  • the frames it emits are not S1G Beacons (Type/Subtype 0x0031) but Action frames (Type 0x000D), category 221 i.e. vendor-specific;
  • they are sent every 2 seconds, not at the ~102.4 ms beacon interval;
  • in STA mode it sends a Probe Request that never draws a Probe Response, giving the same ieee80211_sta_assoc_timeout I see.

If that also holds for type 5, then my rxq_hwm=0 needs no exotic explanation and no Morse-side bug: there is simply no conformant S1G beacon on the air for a scan to report. It would also explain why the failure is strictly one-way - the part’s receiver handles standard Morse frames fine, while its transmitter is emitting something proprietary.

That has changed my plan: I was about to buy an SDR to check whether the Taixin was radiating off-frequency, and that would have been the wrong instrument entirely.

Hardware question before I spend money. Per MM_APPNOTE-36 the monitor-mode workflow is MM6108 on OpenWrt 2.7.x+, configured via the UI or morse_cli -i mon0 channel ..., captured with SSHdump into Wireshark. Is the HaLowLink 1 ($99 on Mouser) sufficient for exactly that, or does the app note assume an evaluation kit? And is HaLowLink 2 equally capable if I’d rather have the newer hardware?

If so I’ll pick one up, capture the type-5 EVB AP at 1 MHz / 914.5 MHz, and post the pcap here - which should show definitively whether it emits 0x0031 beacons or the same category-221 Action frames. Happy for that capture to be used however is useful to you.

10

Both the HaLowLink 1 and HaLowLink 2 will work as sniffers. Note that the HL1 is AU/US only, while the HL2 will be region locked based on where you purchase from.