ST67W611M1 T02: host-injected DHCP broadcast gets no OFFER on enterprise AP — module-internal DHCP (T01) works on same network

[Yurii Promovych]

## 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)

 

 

[Yurii Promovych]

Hello, ST Community. I want to use radio modules from ST in our new project. Now it is hard to get an OFFER in T02 mission in my corporative network. 

Yurii

[Louis AUDOLY]

Hello ​@Yurii Promovych,

 

If I understood correctly your setup is the following :

-You try to connect to the SSID located in your enterprise BUT with WPA2-personnal encryption

-Using T02 binary + Zephyr host:

    -You cannot get an IP with DHCP from your WPA2-personnal (FortiAP) but the association is successful

    -You can associate and get an IP when you connect to another AP (here a mobile hotspot) with the same software configuration

-Using T01 binary + X-CUBE-ST67W61, ST67W6X_CLI firmware (for example):

    -You can associate and get and IP from FortiAP.

 

Could you please :

-Confirm you are not trying to connect to an AP with the WPA2-Enterprise security

-Verify you are not in low power when starting the DHCP sequence

-Capture and provide Wireshark traces of the full sequence to be able to fully understand what's happening

-Provide logs from the AP during the sequence capture by Wireshark

-Try to connect to your FortiAP with the following software setup : 

    -T02 binary + ST67W6X_CLI_LWIP host application from X-CUBE-ST67W61 software package.

 

Regards

Louis

[Yurii Promovych]

Hello Louis,

Thank you for your fast reply. Answers to your points:

1. Security. We confirm it is WPA2-Personal (WPA2-PSK), not WPA2-Enterprise. The driver reports: Security WPA2-PSK, Wi-Fi 6 (802.11ax), 2.4 GHz.

2. Low power. The host never enables power save: no AT+PWR command is sent at any time. The only related setup command is AT+SLWKDTIM=1. Power save on our side would not explain the result either. A second station on the same AP, awake and running Wireshark, sees all our DISCOVERs but no OFFER at all, so the server never sends one.

3. Wireshark traces. Attached (anonymised). While capturing, we found the cause:

The T02 firmware transmits every Ethernet frame as 1514 bytes, whatever DL the host writes in the SPI header.
For example, a 44-byte ICMP echo reply goes out as 1514 bytes.
Counters in our host driver show that the largest DL we ever wrote was 699 bytes.
Frames from other stations on the same AP have their normal length.
The padding contains stale data from earlier transmitted frames.
In 11 of 15 echo replies, the bytes after the IP datagram are the tail of a previous frame, e.g. our earlier MQTT PUBLISH (topic and JSON payload).
So data sent to one peer is re-transmitted to others, and in broadcast frames to every station in range. This is an information leak of the "Etherleak" type (CVE-2003-0001). Please also forward it to ST PSIRT.
This breaks DHCP on our Fortinet network.
We reproduced it from a PC, without the ST67, by sending DISCOVERs for the PC's own MAC.
Frames of 342–1450 bytes always get an OFFER. 1514-byte frames, broadcast or unicast to the server, never do.
Other 1514-byte traffic is forwarded normally.
This explains why T01 works (correctly sized frames) and why a phone hotspot works (its DHCP server tolerates the trailer).

The attached report has the full data and steps to reproduce.

4. AP logs. The network is managed by our IT department and it will be difficult to do this. The PC test above already shows that the server does not answer DHCP in 1514-byte frames.

5. T02 + ST67W6X_CLI_LWIP. We have not run it yet. The quickest check is in your lab with any T02 host:

Ping the module with a small payload, e.g. ping -l 8.
Capture on a second station.
Look at the frame length and the bytes after the IP datagram.

If your host gets correctly sized frames, please tell us what it does differently in the SPI header (for example a flag in the "frame" byte), and we will change our driver.

Could you also tell us whether a T02 build that transmits exactly DL bytes is planned? We can test pre-release builds.

Thank You for Your help,
Yurii Promovych

[Louis AUDOLY]

Hello ​@Yurii Promovych ,

We've been able to reproduce the behavior with T02 binary + ST67W6X_CLI_LWIP host application.

We are currently investigating on this topic and will let you know when we have a fix.

Regards

Louis

[Yurii Promovych]

Thank you!