# Trying to connect Lilygo T-Halow client to MM8108-EKH19 AP **URL:** \ **Category:** Hardware\ **Created:** [June 6, 2026, 2:04pm UTC](https://community.morsemicro.com/t/trying-to-connect-lilygo-t-halow-client-to-mm8108-ekh19-ap/1715 "2026-06-06T14:04:31Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![Stanley](https://avatars.discourse-cdn.com/v4/letter/s/7ab992/32.png) [@Stanley](https://community.morsemicro.com/u/Stanley)\ **Post date:** [June 6, 2026, 2:04pm UTC](https://community.morsemicro.com/t/trying-to-connect-lilygo-t-halow-client-to-mm8108-ekh19-ap/1715/1 "2026-06-06T14:04:31Z")
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) ---
**Author:** ![Stanley](https://avatars.discourse-cdn.com/v4/letter/s/7ab992/32.png) [@Stanley](https://community.morsemicro.com/u/Stanley)\ **Post date:** [June 8, 2026, 3:41pm UTC](https://community.morsemicro.com/t/trying-to-connect-lilygo-t-halow-client-to-mm8108-ekh19-ap/1715/2 "2026-06-08T15:41:42Z")
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. ---
**Author:** ![ajudge](https://avatars.discourse-cdn.com/v4/letter/a/c2a13f/32.png) [@ajudge](https://community.morsemicro.com/u/ajudge)\ **Post date:** [June 9, 2026, 4:54am UTC](https://community.morsemicro.com/t/trying-to-connect-lilygo-t-halow-client-to-mm8108-ekh19-ap/1715/3 "2026-06-09T04:54:00Z")
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](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. ---
**Author:** ![castironclay](https://avatars.discourse-cdn.com/v4/letter/c/da6949/32.png) [@castironclay](https://community.morsemicro.com/u/castironclay)\ **Post date:** [June 9, 2026, 10:28pm UTC](https://community.morsemicro.com/t/trying-to-connect-lilygo-t-halow-client-to-mm8108-ekh19-ap/1715/4 "2026-06-09T22:28:43Z")
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 😉 No real answers for you but hopefully you feel less crazy. ---
**Author:** ![jasonhao](https://avatars.discourse-cdn.com/v4/letter/j/ad7895/32.png) [@jasonhao](https://community.morsemicro.com/u/jasonhao)\ **Post date:** [June 10, 2026, 1:52pm UTC](https://community.morsemicro.com/t/trying-to-connect-lilygo-t-halow-client-to-mm8108-ekh19-ap/1715/5 "2026-06-10T13:52:22Z")
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. ---
**Author:** ![pebkac](https://avatars.discourse-cdn.com/v4/letter/p/cdc98d/32.png) [@pebkac](https://community.morsemicro.com/u/pebkac)\ **Post date:** [August 18, 2026, 4:39pm UTC](https://community.morsemicro.com/t/trying-to-connect-lilygo-t-halow-client-to-mm8108-ekh19-ap/1715/6 "2026-08-18T16:39:15Z")
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](https://github.com/Taixin-Semiconductor/TXW8301_FMAC/issues/1) 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? ---
**Author:** ![pebkac](https://avatars.discourse-cdn.com/v4/letter/p/cdc98d/32.png) [@pebkac](https://community.morsemicro.com/u/pebkac)\ **Post date:** [August 20, 2026, 1:46pm UTC](https://community.morsemicro.com/t/trying-to-connect-lilygo-t-halow-client-to-mm8108-ekh19-ap/1715/7 "2026-08-20T13:46:10Z")
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: 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. ---
**Author:** ![ajudge](https://avatars.discourse-cdn.com/v4/letter/a/c2a13f/32.png) [@ajudge](https://community.morsemicro.com/u/ajudge)\ **Post date:** [August 20, 2026, 3:46pm UTC](https://community.morsemicro.com/t/trying-to-connect-lilygo-t-halow-client-to-mm8108-ekh19-ap/1715/8 "2026-08-20T15:46:54Z")
> [@pebkac](#): > > 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”? 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! > [@pebkac](#): > > 1. 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. 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. > [@pebkac](#): > > 1. 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? 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](https://www.morsemicro.com/resources/appnotes/MM_APPNOTE-36_How_to_do_a_Sniffer_Capture.pdf) ---
**Author:** ![pebkac](https://avatars.discourse-cdn.com/v4/letter/p/cdc98d/32.png) [@pebkac](https://community.morsemicro.com/u/pebkac)\ **Post date:** [August 20, 2026, 4:27pm UTC](https://community.morsemicro.com/t/trying-to-connect-lilygo-t-halow-client-to-mm8108-ekh19-ap/1715/9 "2026-08-20T16:27:08Z")
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. ---
**Author:** ![james.haggerty](https://avatars.discourse-cdn.com/v4/letter/j/c68b51/32.png) [@james.haggerty](https://community.morsemicro.com/u/james.haggerty)\ **Post date:** [August 21, 2026, 3:47am UTC](https://community.morsemicro.com/t/trying-to-connect-lilygo-t-halow-client-to-mm8108-ekh19-ap/1715/10 "2026-08-21T03:47:31Z")
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.