HaLowLink2 compatibility with TXW8301


| / | __ _ __ __ __ | / (*) __ _ __ __
| |/| |/ _ | '__/ __|/ _ \ | |/| | |/ | '/ _
| | | | () | | __ \ / | | | | | (| | | () |
|| ||_
_/|| |/_| || ||*|_|_| _/


OpenWrt 23.05.6, Morse-2.11.13

root@halowlink2-908b:~# logread -f | grep hostapd_s1g
Sun May 24 00:57:10 2026 daemon.info hostapd_s1g: wlan0: STA ce:4f:26:8f:aa:88 IEEE 802.11: authenticated
Sun May 24 00:57:21 2026 daemon.info hostapd_s1g: wlan0: STA ce:4f:26:8f:aa:88 IEEE 802.11: authenticated
Sun May 24 00:57:33 2026 daemon.notice hostapd_s1g: wlan0: STA ce:4f:26:8f:aa:88 IEEE 802.11: did not acknowledge authentication response
Sun May 24 00:57:43 2026 daemon.notice hostapd_s1g: wlan0: STA ce:4f:26:8f:aa:88 IEEE 802.11: did not acknowledge authentication response
Sun May 24 00:57:55 2026 daemon.info hostapd_s1g: wlan0: STA ce:4f:26:8f:aa:88 IEEE 802.11: authenticated
Sun May 24 00:58:05 2026 daemon.notice hostapd_s1g: wlan0: STA ce:4f:26:8f:aa:88 IEEE 802.11: did not acknowledge authentication response
Sun May 24 00:58:15 2026 daemon.info hostapd_s1g: wlan0: STA ce:4f:26:8f:aa:88 IEEE 802.11: authenticated
Sun May 24 00:58:27 2026 daemon.notice hostapd_s1g: wlan0: STA ce:4f:26:8f:aa:88 IEEE 802.11: did not acknowledge authentication response
Sun May 24 00:58:39 2026 daemon.info hostapd_s1g: wlan0: STA ce:4f:26:8f:aa:88 IEEE 802.11: authenticated
Sun May 24 00:58:49 2026 daemon.info hostapd_s1g: wlan0: STA ce:4f:26:8f:aa:88 IEEE 802.11: authenticated
Sun May 24 00:59:00 2026 daemon.notice hostapd_s1g: wlan0: STA ce:4f:26:8f:aa:88 IEEE 802.11: did not acknowledge authentication response
Sun May 24 00:59:10 2026 daemon.notice hostapd_s1g: wlan0: STA ce:4f:26:8f:aa:88 IEEE 802.11: did not acknowledge authentication response

CLIENT LOG ANALYSIS AND AP CORRELATION DIAGNOSIS

The log you provided is a client-side driver log. When analyzed together with
the previously examined AP-side hostapd log (“did not acknowledge
authentication response”), it helps reveal the root cause of the problem.

This log clearly shows that the connection between the AP (50:2e:91:d2:c4:c9)
and the client (ce:4f:26:8f:aa:88) is failing at the Association stage.


  1. LOG ANALYSIS SUMMARY

Item : Value
------------------±------------------------------------------------
Client MAC : ce:4f:26:8f:aa:88 (local in LMAC STATUS)
AP MAC : 50:2e:91:d2:c4:c9
SSID : hgic_ah_test
Channel : 1 (S1G channel 1, freq 916.5MHz)
Failure Stage : Association (assoc_resp status_code=1)


  1. KEY LOG MESSAGE INTERPRETATION

2.1 ieee80211_sta_select_bss:24::by SSID find hgic_ah_test
[50:2e:91:d2:c4:c9] at channel 1

-> The client discovered the AP (50:2e:91:d2:c4:c9) with SSID
   "hgic_ah_test" on channel 1.

2.2 vif1 state WPA_SCANNING → WPA_AUTHENTICATING

-> The client attempts authentication with the AP.

2.3 vif1 state WPA_AUTHENTICATING → WPA_ASSOCIATING

-> Authentication completed successfully, transitioning to the
   Association stage.

2.4 ieee80211_sta_rx_assoc_resp:246::assoc_resp status_code= 1
[CRITICAL ERROR]

-> The AP rejected the client's Association Request.
-> status_code= 1 means "Unspecified Failure".
-> This is the code used by the AP when rejecting an Association in
   the IEEE 802.11 standard, and it does not specify the exact reason.

2.5 lmac set GTK: cmd=1 addr=50:2e:91:d2:c4:c9 cipher= 0x0 flags= 0x0
keyidx= 0 keylen= 0

-> Attempt to set the GTK (Group Temporal Key).
-> cipher= 0x0 indicates that encryption is not configured.

2.6 del_STA: addr=50:2e:91:d2:c4:c9

-> The AP deletes the client from its association list.

2.7 vif1 state WPA_ASSOCIATING → WPA_DISCONNECTED

-> The connection has been terminated.

2.8 vif1 state WPA_DISCONNECTED → WPA_AUTHENTICATING → WPA_SCANNING

-> It returns to the authentication and scanning stage to retry.

  1. CORRELATION WITH AP LOG

Comparing with the AP-side log analyzed earlier reveals an interesting
pattern.

Stage | Client Log | AP Log
------±------------------------------------±------------------------------
1 | WPA_AUTHENTICATING | authenticated (auth succeeded)
2 | WPA_ASSOCIATING | (Association response sent)
3 | assoc_resp status_code= 1 | did not acknowledge auth resp
4 | WPA_DISCONNECTED | (connection terminated)

KEY ISSUE:

  • The AP sent an Authentication Response, but the client did NOT send an
    ACK, so the AP treated it as authentication failure
    (“did not acknowledge authentication response”).

  • However, in the client log, authentication APPEARS to have succeeded
    (WPA_AUTHENTICATING → WPA_ASSOCIATING), and it moved on to the
    Association stage.

  • Yet the AP rejected the Association with status_code= 1
    (Unspecified Failure).

This indicates a STATE MISMATCH between the client and the AP.
The client believes authentication succeeded, but the AP considers
authentication to have failed and rejects the Association.


  1. ESTIMATED CAUSES

4.1 Authentication Response ACK Loss (Most Likely)

- The AP sent an authentication response, but the client failed to
  send an ACK.
- The client received the authentication response but either failed
  to send the ACK, or the ACK did not reach the AP.
- As a result, the AP treated it as authentication failure while the
  client treated it as success, creating a state mismatch.

4.2 Security Configuration Mismatch

- The security settings (WPA2/WPA3, encryption method) between the
  client and AP may not match.
- If the AP is configured with "encryption 'none'" and the client
  attempts WPA authentication, the AP may reject it.

4.3 HaLow (S1G) Characteristics

- HaLow is a standard for low-power, long-range communication and has
  different characteristics from regular Wi-Fi.
- In particular, RAW (Restricted Access Window) settings may not be
  compatible between the client and AP.

4.4 Signal Quality Issues

- bgr: -108 (Background RSSI) indicates a very weak signal strength.
- Poor signal quality increases the likelihood of ACK frame loss.

4.5 Channel Mismatch

- The client log shows "channel 1", while the AP log shows
  "S1G operating channel 29".
- This may be due to the mapping difference between S1G channels and
  HT channels. (S1G channel 29 = HT channel 116 = freq 916.5MHz)
- However, it is necessary to verify that the client and AP are using
  the same channel.

  1. SOLUTIONS

5.1 Match Security Settings

- Change the AP setting to 'psk2' (WPA2-PSK).
- Ensure the client uses the same security settings.

5.2 Improve Signal Quality

- Reduce the distance between the AP and client, or adjust antenna
  orientation.
- bgr: -108 indicates a very weak signal, so signal strength must be
  increased.

5.3 Re-check AP Configuration

# Check wireless settings on the AP
cat /etc/config/wireless

# Check hostapd configuration file
cat /var/run/hostapd-phy0.conf

5.4 Increase hostapd Log Level

# Add to the wifi-device section in /etc/config/wireless
option log_level '2'

# Apply the configuration
wifi reload

# Check detailed logs
logread -f | grep hostapd_s1g

5.5 Check Client Driver Logs

- Increase the client driver log level to obtain more detailed logs.
- In particular, check for additional information about
  status_code= 1 in assoc_resp.

5.6 Test Channel Change

- Change the AP channel to avoid interference.
- Example: channels 27, 29, 31, etc.

  1. CONCLUSION AND SUMMARY

This log shows that the client succeeded in authentication with the AP but
was rejected at the Association stage with status_code= 1
(Unspecified Failure).

Combined with the AP log’s “did not acknowledge authentication response”,
the most likely cause is a state mismatch due to authentication response
ACK loss.


  1. SUMMARY TO SEND TO JAMES HAGGERTY

"The client (ce:4f:26:8f:aa:88) succeeded in authentication with the AP
(50:2e:91:d2:c4:c9) but was rejected at the Association stage with
status_code= 1 (Unspecified Failure).

The AP log repeatedly shows ‘did not acknowledge authentication response’,
suggesting a state mismatch due to authentication response ACK loss.

The signal strength is very weak at -108dBm, and the security setting
(encryption ‘none’) also needs to be verified."

client log

-------------------
[151084]LMAC STATUS:
local: ce:4f:26:8f:aa:88 AID= 0 mode= 0(0/1:STA;2:AP)
freq= 916.5 bw=1 bgr=-107 dc=0:0(5:44)
chn: 916.5
bgr: -108
buf: free=65 tq=0 sq=0
irq: ac=31 bkn=0 bo(rts:frm)=0:0:0:0:31 to(rts:frm)=0:0 rx=65
tx : cnt=31 dly=0:0ms est_rate=900kbps txp=0 fail=0 drop=0
rx : cnt=65 bus=0ms
cca: st12= 0:0 mid1224= 0:0:0:0
chip-temperature:33, vcc:3.37, vdd13b:1.35, vdd13c:1.34
sta_list: no sta

[40;31m[155652]ieee80211_sta_select_bss:24::by SSID find hgic_ah_test [50:2e:91:d2:c4:c9] at channel 1
[0m[155661]vif1 state WPA_SCANNING → WPA_AUTHENTICATING
[155671]vif1 state WPA_AUTHENTICATING → WPA_ASSOCIATING
[155686]bss max idle: 300 x 1000TUs
[40;31m[155688]ieee80211_st[155690]bss max idle: 300 x 1000TUs
a 300 x 1000TUs
6::assoc_resp status_code= 1
[0m[155698][155699]bss max idle: 300 x 1000TUs
iss max idle: 300[155703]bss max idle: 300 x 1000TUs
x 1000TUs
x200490e0. 50:2e:91:d2:c4:c9
[155710]lmac set GTK: cmd=1 addr=50:2e:91:d2:c4:c9 cipher= 0x0 flags= 0x0 keyidx= 0 keylen= 0
[155718]del_STA: addr=50:2e:91:d2:c4:c9
[155722]stamap=0x0
[155724]sleepmap=0x0
[155726]vif1 state WPA_ASSOCIATING → WPA_DISCONNECTED
[155731]vif1 state WPA_DISCONNECTED → WPA_AUTHENTICATING
[155736]vif1 state WPA_AUTHENTICATING → WPA_SCANNING

AP log

OpenWrt 23.05.6, Morse-2.11.13

root@halowlink2-908b:~# logread -f | grep hostapd_s1g
Sun May 24 00:57:10 2026 daemon.info hostapd_s1g: wlan0: STA ce:4f:26:8f:aa:88 IEEE 802.11: authenticated
Sun May 24 00:57:21 2026 daemon.info hostapd_s1g: wlan0: STA ce:4f:26:8f:aa:88 IEEE 802.11: authenticated
Sun May 24 00:57:33 2026 daemon.notice hostapd_s1g: wlan0: STA ce:4f:26:8f:aa:88 IEEE 802.11: did not acknowledge authentication response
Sun May 24 00:57:43 2026 daemon.notice hostapd_s1g: wlan0: STA ce:4f:26:8f:aa:88 IEEE 802.11: did not acknowledge authentication response
Sun May 24 00:57:55 2026 daemon.info hostapd_s1g: wlan0: STA ce:4f:26:8f:aa:88 IEEE 802.11: authenticated
Sun May 24 00:58:05 2026 daemon.notice hostapd_s1g: wlan0: STA ce:4f:26:8f:aa:88 IEEE 802.11: did not acknowledge authentication response
Sun May 24 00:58:15 2026 daemon.info hostapd_s1g: wlan0: STA ce:4f:26:8f:aa:88 IEEE 802.11: authenticated
Sun May 24 00:58:27 2026 daemon.notice hostapd_s1g: wlan0: STA ce:4f:26:8f:aa:88 IEEE 802.11: did not acknowledge authentication response
Sun May 24 00:58:39 2026 daemon.info hostapd_s1g: wlan0: STA ce:4f:26:8f:aa:88 IEEE 802.11: authenticated
Sun May 24 00:58:49 2026 daemon.info hostapd_s1g: wlan0: STA ce:4f:26:8f:aa:88 IEEE 802.11: authenticated
Sun May 24 00:59:00 2026 daemon.notice hostapd_s1g: wlan0: STA ce:4f:26:8f:aa:88 IEEE 802.11: did not acknowledge authentication response
Sun May 24 00:59:10 2026 daemon.notice hostapd_s1g: wlan0: STA ce:4f:26:8f:aa:88 IEEE 802.11: did not acknowledge authentication response

Hi @yuhan

I have a TXW8301 and can reproduce your same issue using the AT commands as documented at taixin_tools/docs/at_commands_2x_firmware.md at main · aliosa27/taixin_tools · GitHub

The TXW8301 attempts authentication with the HaLowLink2 but it attempts this with the wrong authentication algorithm in Sequence 1 of the authentication process, the TXW8301 is sending this commit with “Open System”. Following this with the Association Request - the TXW8301 appears to attempt to associate with WPA1 - indicated by the inclusion of the WPA Information element. This element is also malformed.

The HaLowLink2 is rejecting this association with an “Unspecified Error”, likely caused by the malformed packet.

This is not WPA3 which is required for Wi-Fi HaLow. Taixin claim WPA3 certification (and there is a publicly available report) so there must be some way to use WPA3 with these devices. I would strongly recommend asking Taixin how to configure the device to use WPA3.

1 Like

Hi ajudge,
Thank you so much for taking the time to look into this and successfully reproduce the issue.
I also really appreciate being able to refer to the documentation you provided regarding
the authentication process.

Your detailed technical analysis—specifically regarding the “Open System” commit in Sequence 1
and the malformed WPA1 Information Element—perfectly explains the “Unspecified Error” I have
been encountering. It is incredibly helpful and reassuring to have this behavior confirmed by
someone else working with the same hardware.

I completely agree with your recommendation. I will reach out to Taixin support directly,
share this sniffer trace analysis, and ask for the specific AT commands, configuration steps,
or firmware updates required to properly enable WPA3 on the TXW8301.

Additionally, I am considering pivoting my device development to use the MM8108-EKH05 instead.
Could you kindly share any advice or easy starting points for getting up and running with this kit?
I am specifically planning to set up my development environment on Windows, so any recommendations
for Windows-friendly toolchains, SDKs, or getting-started guides would be highly appreciated.

Thanks again for your valuable insight and for pointing me in the right direction!
Best regards,
Yuhan

For a Windows development environment the best place to start would be the CMSIS pack we have available at GitHub - MorseMicro/mm-iot-cmsis · GitHub
Additional documentation is available at https://www.morsemicro.com/resources/user_guides/MM-IoT-CMSIS-Pack-User-Guide.pdf which should help guide you through the pack.


The MM IoT SDK is the core SDK here that the CMSIS pack is based on, and both will nudge you towards using FreeRTOS on your host microcontroller. If you want to use Zephyr instead, I’d recommend looking at the Zephyr port, however this does come currently come with some throughput limitations.

1 Like

Hi ajudge,
Thank you so much for pointing me to the CMSIS pack and the User Guide.
This is exactly the clear direction I needed to get started.

I truly appreciate the detailed heads-up regarding the MM IoT SDK, the recommendation to use
FreeRTOS on the host microcontroller, and the transparency about the current throughput
limitations of the Zephyr port. This information is incredibly valuable for planning my
Windows-based development environment effectively.

I will carefully review the GitHub repository and the documentation you provided,
and I am excited to dive into the MM8108-EKH05 development using these resources.
I will do my best to make solid progress!

Thanks again for your continued support, valuable insights, and
for always pointing me in the right direction.

Best regards,
Yuhan

Hi ajudge,

I am currently implementing a ping test program.
However, I cannot find detailed information on the required architecture or structure.

  1. pack 1.7.4
  2. mm-iot-sdk-2.9.7-mm8108
  3. Compilation is complete.

The ping test has not been performed yet.

I would like to know the next steps to take from this point.
Could you please explain the procedure for developing a standard application?

Best regards,
Yuhan

Halow_Ping_17.txt (15.2 KB)

Core.zip (29.8 KB)

Hi @yuhan

If you’re just getting started, I would recommend updating to the latest version of CMSIS pack. There has been a lot of work on both the code as well as documentation that you will benefit from.

The latest release is 1.10.2 Release 1.10.2 · MorseMicro/mm-iot-cmsis · GitHub (1.11 should be released very soon).

You can find the release notes here: CMSIS Pack Software Release Notes | Software releases | Morse Micro documentation

And the significantly updated user guide is here: https://www.morsemicro.com/resources/user_guides/MM-IoT-CMSIS-Pack-User-Guide.pdf

Have a go with the updated guide + updated package and see if that helps with your progress!

AP 연결

STA 의 경우에

-----------------------------------
Initialize IPv4 using DHCP…
Initialize IPv6 using Autoconfig…
Morse LwIP interface initialised. MAC address 0c:bf:74:00:1f:49
Attempting to connect to MorseMicro with passphrase 12345678
This may take some time (~10 seconds)
WLAN STA connecting
WLAN STA connected
DNS server 0: 192.168.12.1
Link is up. Time: 8272 ms, IP: 192.168.12.135, Netmask: 255.255.255.0, Gateway: 192.168.12.1, DNS server 0: 192.168.12.1

[Monitor] Starting periodic ping and RSSI monitoring…
[Monitor] Ping target can be configured via ‘ping.target’ (persistent store)
[RSSI] -57 dBm
[Ping] Target: 192.168.12.1, 32 bytes
[Ping] Start failed
mdns status[netif 0][service 0]: 1
[RSSI] -57 dBm
[Ping] Target: 192.168.12.1, 32 bytes
[Ping] Start failed
[RSSI] -56 dBm
[Ping] Target: 192.168.12.1, 32 bytes
[Ping] Start failed
[RSSI] -56 dBm
[Ping] Target: 192.168.12.1, 32 bytes
[Ping] Start failed
[RSSI] -56 dBm

출력이 되고 있다.. AP에 연결은 되었지만 Ping 에 대한 응답 신호가 없습니다.

change code part " http.c 의 app_init()"

void app_init(void)
{
struct netif *mmnetif;
char strval[8];
const struct mmwlan_s1g_channel_list *channel_list;

printf("\n\nEKH05 Demo Example(Built " __DATE__ " " __TIME__ ")\n\n");
periphs_start();

ping_init();
iperf_init();
shared_buffer_init(&http_terminal_buffer);

#ifndef LIMITED_DEMO_EXAMPLE
(void)mmosal_safer_strcpy(strval, “??”, sizeof(strval));
(void)mmconfig_read_string(“wlan.country_code”, strval, sizeof(strval));
channel_list = mmwlan_lookup_regulatory_domain(get_regulatory_db(), strval);
if (channel_list == NULL)
{
printf(“Could not find specified regulatory domain matching country code %s\n”, strval);
printf(“Please set the configuration key wlan.country_code to the correct country code.\n”);
return;
}

app_wlan_init();
app_wlan_start();
mmnetif = get_mmnetif();

update_ble_ip_report(mmnetif);

LOCK_TCPIP_CORE();
mdns_init(mmnetif);
rest_init_endpoints(rest_endpoints, LWIP_ARRAYSIZE(rest_endpoints));
http_set_cgi_handlers(cgi_endpoints, LWIP_ARRAYSIZE(cgi_endpoints));
httpd_init();
UNLOCK_TCPIP_CORE();

/* ===== 주기적 Ping + RSSI 모니터링 시작 ===== */
printf("\n[Monitor] Starting periodic ping and RSSI monitoring...\n");
printf("[Monitor] Ping target can be configured via 'ping.target' (persistent store)\n");

struct mmping_args ping_args = MMPING_ARGS_DEFAULT;
ping_args.ping_size = 32;           /* 32바이트 페이로드 */
ping_args.ping_count = 3;           /* 각 세션당 3회 ping */
ping_args.ping_interval_ms = 1000;  /* 1초 간격 */

while (1)
{
    /* 1. 지속성 저장소에서 ping.target 읽기 (외부 설정 지원) */
    (void)mmconfig_read_string("ping.target", ping_args.ping_target, sizeof(ping_args.ping_target));
    if (ping_args.ping_target[0] == '\0') {
        /* 구성이 없으면 기본값 사용: AP 게이트웨이 */
        mmosal_safer_strcpy(ping_args.ping_target, "192.168.12.1", sizeof(ping_args.ping_target));
    }

    /* 2. RSSI 읽기 및 출력 */
    int32_t rssi = mmwlan_get_rssi();
    if (rssi != INT32_MIN) {
        printf("[RSSI] %ld dBm\n", (long)rssi);
    } else {
        printf("[RSSI] read error\n");
    }

    /* 3. Ping 세션 시작 */
    printf("[Ping] Target: %s, %lu bytes\n",
           ping_args.ping_target, (unsigned long)ping_args.ping_size);

    uint16_t ping_id = mmping_start(&ping_args);
    if (ping_id == 0) {
        printf("[Ping] Start failed\n");
        mmosal_task_sleep(5000);
        continue;
    }

    /* 4. 이번 Ping 세션 완료 대기 (결과 출력 포함) */
    struct mmping_stats stats;
    unsigned last_recv_count = 0;
    mmping_stats(&stats);

    while (stats.ping_is_running)
    {
        mmosal_task_sleep(500);
        mmping_stats(&stats);

        if (stats.ping_recv_count != last_recv_count) {
            printf("[Ping] tx=%lu, rx=%lu, min/avg/max = %lu/%lu/%lu ms\n",
                   (unsigned long)stats.ping_total_count,
                   (unsigned long)stats.ping_recv_count,
                   (unsigned long)stats.ping_min_time_ms,
                   (unsigned long)stats.ping_avg_time_ms,
                   (unsigned long)stats.ping_max_time_ms);
            last_recv_count = stats.ping_recv_count;
        }
    }

    /* 5. Ping 세션 최종 결과 출력 */
    mmping_stats(&stats);
    printf("[Ping] Session done: %lu/%lu received, avg RTT=%lu ms\n\n",
           (unsigned long)stats.ping_recv_count,
           (unsigned long)stats.ping_total_count,
           (unsigned long)stats.ping_avg_time_ms);

    /* 6. 5초 주기 제어 (RSSI 및 Ping 전체 루프) */
    mmosal_task_sleep(5000);
}
/* ===== 주기적 모니터링 종료 ===== */

#endif
}

How should I set up the AP and device environment?

  1. Ping test
  2. Data transmission/reception test

What is the best approach to implement these two functions?

  • Connecting to the device via an external app to send pings and data.
  • Connecting to the AP via an external app to perform ping tests and data transmission.

I am planning to implement a test program based on this type of structure.

Thank you.

It looks like you’ve missed setting the ping source address, see here as an example:

I would recommend you start with updating to the latest version of the CMSIS pack, then starting with the existing ping example application. Once you have that working, and you know the basic setup is correct, then start developing a custom application.

I have defined the following in the configs.c file.

#include “mmconfig.h”

const struct mmconfig_literal_config mm_litral_configs={
/* udp_server /
{“iperf.mode”, “udp_server”},
/
IP address of server to connect to when in client mode /
{“iperf.server”, “192.168.12.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.12.1"},
    {"ping.count", "10"},
    {"ping.interval", "1000"},
    {"ping.size", "56"},
    {"ping.post_ping_delay_ms", "60000"},

    /* 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", "12345678"},
    /* 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","AU"},

    /* 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.12.2"},
    {"ip.netmask", "255.255.255.0"},
    {"ip.gateway", "192.168.12.1"},

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

Device ping test successful.

I would like to know how to perform a ping test on the Halowlink2.

AP ping test successful.

However, it would be ideal if background information from the AP—such as SNR and RSSI—could also be displayed. other info…

RTT Stabilization: Disable PSM (mmwlan_set_power_save_mode(MMWLAN_PS_NONE))
Throughput Measurement: Measure TCP/UDP bandwidth using the iperf command
RF Characteristic Analysis: Monitor RSSI, MCS, and PER (Packet Error Rate)
Long-range Test: Observe changes in RSSI/RTT while increasing the distance between the device and the AP
Power Consumption Measurement: Measure current differences with PSM enabled vs. disabled

I would like to obtain the Ping test results as well as the RSSI, SNR, and MCS values.
I have already completed the Ping test, but I would like to know the commands to view the RSSI, SNR, and MCS values ​​via the terminal on the Halowlink2.

Hey @yuhan

the best way to view rssi, snr, and mcs stats on the HaLowLink2 console is to use the iwinfo <iface> assoclist command. The output will look like:

# iwinfo wlh0 assoclist
0C:BF:74:ab:cd:ef  -33 dBm / -105 dBm (SNR 72)  152170 ms ago
        RX: 3.4 MBit/s, MCS 7, 1MHz                      339 Pkts.
        TX: 3.4 MBit/s, MCS 7, 1MHz                      159 Pkts.
        expected throughput: 3.3 MBit/s
1 Like

The setup on the Halowlink2 is currently as shown above,

and the implementation on the STM32 is as follows.
I would like to know if there is a way to view the SNR value while in development mode.

I am currently working on a program for field testing scheduled for tomorrow, and it would be helpful to be able to see these values.

Additionally, I would like to have a “Power Reset” command available,

as there appear to be some issues when the RF connection is lost.

================================================================================

AP vs. STA Dashboard Measurement Items Comparison

Both dashboards are used to test Morse Micro HaLow devices. The AP (Access
Point) dashboard focuses on detailed RF physical layer diagnostics, while the
STA (Station) dashboard focuses on MCS performance testing and serial logs.

================================================================================

[ COMPARISON TABLE ]

±-----------------------±-----------------------±----------------------------------±----------------------------------+
| Category | Measurement Item | AP Dashboard | STA Dashboard |
±-----------------------±-----------------------±----------------------------------±----------------------------------+
| Connection & Settings | Port / Baud | None | COM35 / 115200 |
| | Target IP / Host | 192.168.12.135 | 192.168.12.1 |
| | Packet Size | 56 | 56B |
| | Count / Repeat | Count: 1, Repeat: 5s | None (Continuous test) |
| | Reply Timeout | None | 1000ms (Observation Mode) |
| | Records | 4 | 17 |
±-----------------------±-----------------------±----------------------------------±----------------------------------+
| Core Wireless Metrics | RSSI | -34 dBm (Normal) | -54 dBm (Excellent) |
| | SNR | 64 dB (Normal) | – (Not measured) |
| | RX MCS | MCS 0 (1MHz - 0.3 Mbps) | MCS 0 (1MHz/LGI - 100.0% cum.) |
| | TX MCS | MCS 7 (1MHz - 3.0 Mbps) | – (Not measured) |
±-----------------------±-----------------------±----------------------------------±----------------------------------+
| RF / Physical Layer | Link Quality / PER | 91% / 9.63% | None |
| | Noise Floor | -98 dBm | None |
| | Retry / Beacon | 12 max / 111 late | None |
| | Interference / Freq | 0% / -12961 Hz | None |
| | Temperature / MIC Fail | 31 C / 18 cnt | None |
| | PHY LTF Fail | 25780 cnt | None |
±-----------------------±-----------------------±----------------------------------±----------------------------------+
| MCS Performance Test | BW / MCS / GI | None | List (e.g., 1MHz/MCS0/LGI) |
| | Sent / Success (Cum.) | None | 3 / 3 |
| | Success % | None | 100.0% (Best rate indicated) |
±-----------------------±-----------------------±----------------------------------±----------------------------------+
| Ping / Network Stats | Sent / Success | Sent: 4 | Success: 10 |
| | Received / Fail | Received: 4 | Fail: 0 |
| | Lost / Success Rate | Lost: 0 (0.0%) | Success Rate: 100.0% |
| | Avg RTT | 151.7 ms | 16.8 ms |
| | Total Sent | 4 (cumulative) | 17 |
| | Graph (Last 10) | Last 10 attempts RTT bar graph | Round-Robin Last 10 bar graph |
±-----------------------±-----------------------±----------------------------------±----------------------------------+
| Others | Raw Serial Log | None | Real-time serial log output |
±-----------------------±-----------------------±----------------------------------±----------------------------------+

================================================================================

[ SUMMARY OF KEY DIFFERENCES ]

  1. RF Diagnostics vs. MCS Testing

    • AP Dashboard: Provides detailed insights into the health status of the
      hardware and RF environment (e.g., Noise Floor, Freq Offset, PHY LTF Fail).
    • STA Dashboard: Specialized for testing success rates across various
      combinations of MCS and GI through the RC STATS table.
  2. Latency (RTT) Difference

    • AP Dashboard RTT is relatively slow at 151.7 ms.
    • STA Dashboard RTT is very fast at 16.8 ms.
    • This suggests different test conditions (packet size, network load, channel
      state) or that the STA is communicating via a more optimized path.
  3. Logging Feature

    • Only the STA Dashboard includes a “Raw Serial Log” window, allowing users
      to view the raw text logs sent by the device in real-time.

================================================================================