ESP32-C5: Promiscuous callback reports wrong 802.11 frame type
Posted: Wed May 13, 2026 11:36 am
## ESP32-C5: Promiscuous callback reports wrong 802.11 frame type (CTRL → MGMT, DATA → MGMT)
**Chip:** ESP32-C5
**IDF version:** v5.4.2
**Setup:** STA+AP dual-chip, 5GHz Ch40, 802.11n HT20
---
### Summary
The `wifi_promiscuous_pkt_type_t` parameter passed by the driver to the promiscuous callback does not match the actual 802.11 Frame Control field type. Verified by parsing FC from the payload: `(payload[0] >> 2) & 0x03` and comparing against the driver-reported type.
- **ACK frames**: FC Type = Control, driver reports WIFI_PKT_MGMT
- **Data frames sent via esp_wifi_80211_tx()**: FC Type = Data, driver non-deterministically reports WIFI_PKT_MGMT (same frame type, first frame correct, subsequent frames wrong)
CSI subsystem is not affected.
---
### Reproduction
Two C5 boards: one STA, one AP. STA sends a non-QoS Data frame via esp_wifi_80211_tx every 1s to the AP. AP replies with ACK at SIFS.
Both sides enable promiscuous mode with WIFI_PROMIS_FILTER_MASK_ALL. The sniffer callback prints both the driver's `type` and the FC-parsed type for comparison.
---
### Log summary
Alice (STA) receiving ACK from Bob:
drv=MGMT, fc=CTRL (should be CTRL)
Bob (AP) receiving Data from Alice:
Frame N: drv=DATA, fc=DATA (correct)
Frame N+1+: drv=MGMT, fc=DATA (wrong)
All frames confirmed identical via FC field inspection.
---
### Impact
`esp_wifi_set_promiscuous_filter()` type masks (DATA/CTRL/MGMT) are unreliable because frames leak through the wrong category. The only workaround is WIFI_PROMIS_FILTER_MASK_ALL + manual FC parsing.
CSI subsystem (esp_wifi_set_csi_rx_cb) works correctly — the .mac, .dmac, .rx_ctrl fields are accurate.
---
### Question
Is this a known ESP32-C5 issue? Any API or register-level workaround for correct frame type classification in the promiscuous path? Fix planned for a future IDF release? Thanks.
**Chip:** ESP32-C5
**IDF version:** v5.4.2
**Setup:** STA+AP dual-chip, 5GHz Ch40, 802.11n HT20
---
### Summary
The `wifi_promiscuous_pkt_type_t` parameter passed by the driver to the promiscuous callback does not match the actual 802.11 Frame Control field type. Verified by parsing FC from the payload: `(payload[0] >> 2) & 0x03` and comparing against the driver-reported type.
- **ACK frames**: FC Type = Control, driver reports WIFI_PKT_MGMT
- **Data frames sent via esp_wifi_80211_tx()**: FC Type = Data, driver non-deterministically reports WIFI_PKT_MGMT (same frame type, first frame correct, subsequent frames wrong)
CSI subsystem is not affected.
---
### Reproduction
Two C5 boards: one STA, one AP. STA sends a non-QoS Data frame via esp_wifi_80211_tx every 1s to the AP. AP replies with ACK at SIFS.
Both sides enable promiscuous mode with WIFI_PROMIS_FILTER_MASK_ALL. The sniffer callback prints both the driver's `type` and the FC-parsed type for comparison.
---
### Log summary
Alice (STA) receiving ACK from Bob:
drv=MGMT, fc=CTRL (should be CTRL)
Bob (AP) receiving Data from Alice:
Frame N: drv=DATA, fc=DATA (correct)
Frame N+1+: drv=MGMT, fc=DATA (wrong)
All frames confirmed identical via FC field inspection.
---
### Impact
`esp_wifi_set_promiscuous_filter()` type masks (DATA/CTRL/MGMT) are unreliable because frames leak through the wrong category. The only workaround is WIFI_PROMIS_FILTER_MASK_ALL + manual FC parsing.
CSI subsystem (esp_wifi_set_csi_rx_cb) works correctly — the .mac, .dmac, .rx_ctrl fields are accurate.
---
### Question
Is this a known ESP32-C5 issue? Any API or register-level workaround for correct frame type classification in the promiscuous path? Fix planned for a future IDF release? Thanks.