Hello,
I'm using an nRF7002 with an nRF5340 host processor to detect and process WiFi beacon packets in monitor mode. I've encountered an issue where the nRF7002 appears to silently drop 802.11 beacon frames with FCS/CRC errors before they reach the application layer. This is occurring in situations where the number of bytes in a vendor-specific IE payload does not match the length declared by the IE structure.
Here's an example of the vendor-specific IE of a beacon frame (received with a Realtek-based capture device) that would not be captured by the nRF7002 in monitor mode:
Offset Hex Data
---------- ------------------------------------------------
0x0060 dd 53 fa 0b bc 0d 7d f0 19 03 01 12 31 36 36 38
0x0070 42 53 32 30 4a 42 30 30 41 53 33 53 00 00 00 00
0x0080 00 00 00 11 10 00 00 00 00 00 00 00 00 00 00 00
0x0090 00 00 00 00 00 00 00 00 58 3e 08 00 41 01 00 00
0x00a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00b0 ac 18 e9 0c 00 aa 64 6c d4
Relevant notes are:
- Tag 0xDD at offset 0x60 declares length of 83 bytes
- Frame terminates at offset 0xB8 (byte 184)
- Only ~52 bytes of the declared 83-byte payload are present
- Final 4 bytes (aa 64 6c d4) are the FCS, marked as unverified by the driver
This same device transmits regularly and is detected by other WiFi adapters, but the nRF7002 does not detect it in monitor mode despite successfully receiving hundreds of other beacons on the same channel. This suggests the nRF7002 firmware is rejecting these frames at the hardware/firmware level due to FCS validation failure, before they can reach the application layer.
Is there a way to disable FCS validation in monitor mode to allow reception of frames with CRC errors? This would help deal with applications involving real-world devices that have non-compliant WiFi implementations.
