ST67W611M1 T02: host-injected DHCP broadcast gets no OFFER on enterprise AP — module-internal DHCP (T01) works on same network
## Setup
- Module: ST67W611M1 on X-NUCLEO-67W61M1
- Host MCU: STM32C562RE (NUCLEO-C562RE), Zephyr 4.4.0 st67w611m1 driver
(SPI netif path equivalent to W6X_Netif_output / ST67W6X_CLI_LWIP)
- Module firmware: st67w611m_mission_t02_v2.0.106.bin (X-CUBE-ST67W61 v1.3.0)
- Target network: enterprise SSID managed by FortiAP (WPA2)
## Problem
Under mission T02 the station associates successfully, but DHCP never
completes on our enterprise AP. Host-generated DHCP DISCOVER frames sent
through the SPI network-STA path ARE visible on the LAN (captured by a PC
on the same SSID) and are byte-comparable to DISCOVERs from working
clients — yet no OFFER is ever returned.
Control tests:
- T01 firmware, SAME module, SAME MAC, SAME SSID: internal DHCP client
gets a lease within seconds (172.16.1.26).
- T02 firmware on a phone hotspot: SAME host firmware completes DORA
and binds 172.30.234.14.
- Other clients (ESP32, Windows, Android) on the enterprise SSID: work.
So the host stack and the T02 raw frame path are proven correct
end-to-end, and the AP is proven to answer normal DHCP requests.
## Frames verified at host level
- SPI header: magic 0x55AA, len, version/flags, type=1
(SPI_MSG_CTRL_TRAFFIC_NETWORK_STA), rsvd=0 — identical to
spi_iface.h reference
- Payload: complete Ethernet frame, matching W6X_Netif_output()
- Ethernet src = BOOTP chaddr = association MAC 40:82:7B:03:BA:14
- UDP checksum computed in software, non-zero
- Valid BOOTP: broadcast dst, END option present
## Variants tested — no change
- BOOTP options reduced to exactly [53,57,55] like T01's client
- Padded to identical length (312 B)
- Byte-for-byte fingerprint clone of a working ESP32 client's DISCOVER
- MAC spoofed to Espressif OUI, then to the working ESP32's exact MAC
(device powered off)
- Broadcast flag 0x0000 and 0x8000
- T02 firmware v2.0.89, v2.0.97, v2.0.106 — identical behavior
- ARP broadcasts under T02 DO get replies on this AP
## Conclusion
Packet content, MAC consistency and SPI framing are all correct. The
remaining difference is at the 802.11 level: how the module firmware
transmits host-injected frames (T02 netif path) vs frames generated by
its internal stack (T01) — e.g. TX queue, QoS/TID, or 802.11 header
fields that a DHCP-snooping enterprise AP evaluates before forwarding.
## Questions
1. Is this a known limitation of mission T02 (any versions)?
2. Are host-injected broadcast frames transmitted with different 802.11
properties (TID/flags) than internally generated ones?
3. Is there a newer NCP binary addressing broadcast handling in T02?
## Separate issue observed (same module/firmware)
STA association to a Windows 10/11 "Mobile Hotspot" soft-AP fails with
reason code 24 (auth/assoc response confirmation failure), while a phone
connects to the same hotspot. SSID visible at -26 dBm, WPA2-PSK tested
with all keymgmt variants.
================================================================================
Hardware: X-NUCLEO-67W61M1 + NUCLEO-C562RE, Zephyr 4.4.0
Module FW: st67w611m_mission_t02_v2.0.106.bin (X-CUBE-ST67W61 v1.3.0)
================================================================================
--------------------------------------------------------------------------------
1. Host-side hexdump of DHCP DISCOVER as passed to the SPI netif path
(96 bytes, captured in st67_send() before SPI transfer)
Enterprise SSID, station associated, DHCP state=selecting, no OFFER.
--------------------------------------------------------------------------------
STA TX pkt (payload = complete Ethernet frame, no extra headers):
ff ff ff ff ff ff 40 82 7b 03 ba 14 08 00 45 00 |......@. {.....E.
01 54 00 00 00 00 ff 11 ba 99 00 00 00 00 ff ff |.T...... ........
ff ff 00 44 00 43 01 40 e4 9f 01 01 06 00 51 8b |...D.C.@ ......Q.
70 a8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |p....... ........
00 00 00 00 00 00 40 82 7b 03 ba 14 00 00 00 00 |......@. {.......
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |........ ........
Decoded:
Ethernet dst = ff:ff:ff:ff:ff:ff (broadcast)
src = 40:82:7b:03:ba:14 (STA MAC)
ethertype = 0x0800 (IPv4)
IPv4 src = 0.0.0.0, dst = 255.255.255.255, proto = UDP(17)
UDP sport = 68, dport = 67, checksum = 0x518b (computed, non-zero)
BOOTP op=1 htype=1 hlen=6, xid=0x518b70a8
chaddr (offset 70) = 40:82:7b:03:ba:14 <- identical to Ethernet src
END option present in option tail
Consistency check: 802.11 SA == Ethernet src == BOOTP chaddr == 40:82:7b:03:ba:14
(all three fields carry the module's real STA MAC; DHCP-snooping "chaddr==src"
rule is satisfied).
--------------------------------------------------------------------------------
2. Interface identity (Zephyr 'net iface')
wlan1 = STA interface using the real module MAC 40:82:7b:03:ba:14.
(The module additionally exposes a SoftAP interface wlan0 with a locally-
administered virtual MAC 42:82:7b:03:ba:14 = 40:82 | 0x02 — not used by
the STA traffic.)
--------------------------------------------------------------------------------
Interface wlan1 (0x20000798) (WiFi) [2]
===============================
Link addr : 40:82:7B:03:BA:14
MTU : 1500
Flags : AUTO_START,IPv4
Device : st67w611m1@0
Status : oper=UP, admin=UP, carrier=ON
--------------------------------------------------------------------------------
3. Result on enterprise SSID (FortiAP-managed): DISCOVER sent, never answered
The DISCOVER in section 1 was simultaneously captured by a PC on the same
SSID — i.e. it does reach the LAN — but no OFFER follows. Zephyr DHCP
stays in 'selecting' with backoff until timeout, indefinitely.
--------------------------------------------------------------------------------
<dbg> net_dhcpv4: dhcpv4_send_discover: send discover xid=0x518b70a8 timeout=65s
<dbg> net_dhcpv4: dhcpv4_manage_timers: iface 0x20000798 dhcpv4=0x200007a8 state=selecting
... (no 'Received'/bound event; retries continue indefinitely)
--------------------------------------------------------------------------------
4. Control test A — same host firmware, phone hotspot: DHCP completes
--------------------------------------------------------------------------------
<inf> net_dhcpv4: Received: 172.30.234.14
<dbg> net_dhcpv4: dhcpv4_enter_bound: (rx_q[0]): enter state=bound renewal=1799s rebinding=3149s
--------------------------------------------------------------------------------
5. Control test B — same module, mission T01 firmware, same enterprise SSID:
module-internal DHCP client obtains a lease within seconds
(module UART debug console, wifi_sta_info)
--------------------------------------------------------------------------------
wifi_sta_info
================================================================
ANT : 0
RSSI: -56dbm
IP : 172.16.1.26
MASK: 255.255.254.0
GW : 172.16.0.1
DNS : 8.8.8.8
--------------------------------------------------------------------------------
6. Firmware versions tested — identical result on the enterprise SSID
--------------------------------------------------------------------------------
T02 v2.0.106 : associated, DISCOVER on LAN, no OFFER
T02 v2.0.97 : associated, DISCOVER on LAN, no OFFER
T02 v2.0.89 : associated, DISCOVER on LAN, no OFFER
--------------------------------------------------------------------------------
7. Variants already ruled out (no change in behavior)
--------------------------------------------------------------------------------
- BOOTP option set reduced to [53 msg-type, 57 max-size, 55 param-req-list]
- Padded to byte-identical length as a working client's DISCOVER (312 B)
- Full fingerprint clone of a working ESP32 client's DISCOVER
- MAC spoofed to Espressif OUI and to the exact MAC of a working ESP32
- BOOTP broadcast flag 0x0000 and 0x8000
- ARP broadcast frames DO get replies on the same AP under T02
- AT command sequence verified against ST67W6X_Network_Driver middleware
(X-CUBE-ST67W61 v1.3.0): identical init/connect set (CWMODE, CWNETMODE?,
CWAUTOCONN, CIPSTAMAC?, CWLAPOPT, SLWKIO, SLWKDTIM=1, CWJAP)
- Regulatory domain: module reports "00" (same as the SDK default
AT+CWCOUNTRY=0,"00"); explicit AT+CWCOUNTRY=0,"PL" tested — no change
- Host TX queueing: Zephyr driver uses an unbounded k_fifo; SPI TX is not
dropping frames (DISCOVER confirmed on the wire by a LAN-side capture)
