CC3351: Spurious transmission from the CC3351 when initiating a network attach

Part Number: CC3351

Tool/software:

I have ported the “cc33xx_rtos_mcu_package_R7_1” driver to SDIO (it was originally on SPI). Everything works correctly, and I’ve managed to connect to both 2.4 GHz and 5.8 GHz Wi-Fi networks, transmitting packets on each frequency for 24 hours without any loss or TCP retransmissions. However, when I use Wireshark in monitor mode, I see some odd packets: after a Clear-to-Send frame sent by the Linksys router, 16 corrupted frames appear, each filled entirely with the byte 0x1D.

This behavior repeats with different models of Wi-Fi routers.

No. Time Source Destination Protocol Length Info
9958 16.409809 TpLinkTechno_XX:XX:XX TexasInstrum_XX:XX:XX 802.11 358 Probe Response, SN=3736, FN=0, Flags=....R...C, BI=100, SSID="SERGIO"
9959 16.410341 TpLinkTechno_XX:XX:XX WistronNeweb_5d:08:e6 802.11 35 Request-to-send, Flags=........C
9960 16.410353 TpLinkTechno_XX:XX:XX 802.11 29 Clear-to-send, Flags=........C
9961 16.411234 802.11 586 Unknown protocol version: 3
9962 16.411259 TpLinkTechno_XX:XX:XX 802.11 29 Acknowledgement, Flags=........C
9963 16.411356 TpLinkTechno_XX:XX:XX Broadcast 802.11 35 CF-End (Control-frame), Flags=........C
9964 16.412565 TexasInstrum_XX:XX:XX 802.11 29 Clear-to-send, Flags=........C
9965 16.417300 1d:1d:1d:1d:1d:1d 0x1d1d 802.11 815 PV1 Extension (currently reserved)
9966 16.417847 1d:1d:1d:1d:1d:1d 0x1d1d 802.11 815 PV1 Extension (currently reserved)
9967 16.418273 1d:1d:1d:1d:1d:1d 0x1d1d 802.11 815 PV1 Extension (currently reserved)
9968 16.418890 1d:1d:1d:1d:1d:1d 0x1d1d 802.11 815 PV1 Extension (currently reserved)
9969 16.419444 1d:1d:1d:1d:1d:1d 0x1d1d 802.11 815 PV1 Extension (currently reserved)
9970 16.419974 1d:1d:1d:1d:1d:1d 0x1d1d 802.11 815 PV1 Extension (currently reserved)
9971 16.420455 1d:1d:1d:1d:1d:1d 0x1d1d 802.11 815 PV1 Extension (currently reserved)
9972 16.421049 1d:1d:1d:1d:1d:1d 0x1d1d 802.11 815 PV1 Extension (currently reserved)
9973 16.422347 1d:1d:1d:1d:1d:1d 0x1d1d 802.11 1415 PV1 Extension (currently reserved)
9974 16.424148 1d:1d:1d:1d:1d:1d 0x1d1d 802.11 1415 PV1 Extension (currently reserved)
9975 16.425958 1d:1d:1d:1d:1d:1d 0x1d1d 802.11 1415 PV1 Extension (currently reserved)
9976 16.427766 1d:1d:1d:1d:1d:1d 0x1d1d 802.11 1415 PV1 Extension (currently reserved)
9977 16.429766 1d:1d:1d:1d:1d:1d 0x1d1d 802.11 1415 PV1 Extension (currently reserved)
9978 16.431631 1d:1d:1d:1d:1d:1d 0x1d1d 802.11 1415 PV1 Extension (currently reserved)
9979 16.433426 1d:1d:1d:1d:1d:1d 0x1d1d 802.11 1415 PV1 Extension (currently reserved)
9980 16.435231 1d:1d:1d:1d:1d:1d 0x1d1d 802.11 1415 PV1 Extension (currently reserved)

Wireshark information of frame 9972:

Frame 9972: 815 bytes on wire (6520 bits), 815 bytes captured (6520 bits) on interface \Device\NPF_{xxxxxxxxx}, id 0
Radiotap Header v0, Length 15
Header revision: 0
Header pad: 0
Header length: 15
Present flags
Flags: 0x50
Channel frequency: 0
Channel flags: 0x0000
Antenna signal: -11 dBm
802.11 radio information
IEEE 802.11 PV1 Extension (currently reserved)
Frame Control Field: 0x1d1d
Receiver SID
Transmitter address: 1d:1d:1d:1d:1d:1d (1d:1d:1d:1d:1d:1d)
Frame check sequence: 0x180021aa [unverified]
[FCS Status: Unverified]

Where could the problem be?

  • Hello,

    It seems like you are not experiencing any issues, which is good and expected.

    This could be an artifact of the sniffer itself, have you tried another network card or a dedicated sniffer dongle?

    Regards,

    AB

  • Hi AB.

    I got another WiFi sniffer with a different chipset, and the result is still the same:

    No. Time Source Destination Protocol Length Info
    1078 2.987949 TPLink_XX:XX:XX TexasInstrum_XX:XX:XX 802.11 382 Probe Response, SN=2672, FN=0, Flags=........C, BI=100, SSID="SERGIO1"
    1079 2.988242 TexasInstrum_XX:XX:XX 802.11 29 Clear-to-send, Flags=........C
    1080 2.992905 1d:1d:1d:1d:1d:1d 0x1d1d 802.11 815 PV1 Extension (currently reserved)
    1081 2.993450 1d:1d:1d:1d:1d:1d 0x1d1d 802.11 815 PV1 Extension (currently reserved)
    1082 2.993953 1d:1d:1d:1d:1d:1d 0x1d1d 802.11 815 PV1 Extension (currently reserved)
    1083 2.994463 1d:1d:1d:1d:1d:1d 0x1d1d 802.11 815 PV1 Extension (currently reserved)
    1084 2.995021 1d:1d:1d:1d:1d:1d 0x1d1d 802.11 815 PV1 Extension (currently reserved)
    1085 2.995578 1d:1d:1d:1d:1d:1d 0x1d1d 802.11 815 PV1 Extension (currently reserved)
    1086 2.996094 1d:1d:1d:1d:1d:1d 0x1d1d 802.11 815 PV1 Extension (currently reserved)
    1087 2.996741 1d:1d:1d:1d:1d:1d 0x1d1d 802.11 815 PV1 Extension (currently reserved)
    1088 2.998061 1d:1d:1d:1d:1d:1d 0x1d1d 802.11 1415 PV1 Extension (currently reserved)
    1089 3.005786 802.11 1859 Fragmented IEEE 802.11 frame
    1090 3.007144 1d:1d:1d:1d:1d:1d 0x1d1d 802.11 1415 PV1 Extension (currently reserved)
    1091 3.008950 1d:1d:1d:1d:1d:1d 0x1d1d 802.11 1415 PV1 Extension (currently reserved)
    1092 3.010750 1d:1d:1d:1d:1d:1d 0x1d1d 802.11 1415 PV1 Extension (currently reserved)
    1093 3.015979 TexasInstrum_XX:XX:XX TPLink_XX:XX:XX 802.11 133 Probe Request, SN=0, FN=0, Flags=........C, SSID="SERGIO1"
    1094 3.016246 TexasInstrum_XX:XX:XX 802.11 29 Acknowledgement, Flags=........C

    I don't think it's a problem with the sniffer, since I left it capturing for 2 hours with the CC3351 turned off and the 0x1D frame never appeared. Simply turning on the CC3351 causes the frame to appear once, and then it doesn't repeat until the CC3351 is reset.

    Any idea?

  • The cc33xx_rtos_mcu_package_R7_2 firmware continues to present the spurious transmission issue. Has this version been tested over SDIO communication to determine whether the behavior can be replicated?

    Regards

    No. Time Source Destination Protocol Length Info
    334 3.706303 TpLinkTechno_df:08:df TexasInstrum_12:4a:66 802.11 400 Probe Response, SN=1640, FN=0, Flags=........C, BI=100, SSID="SERGIO_EXT"
    335 3.709623 TpLinkTechno_df:08:df TexasInstrum_12:4a:66 802.11 400 Probe Response, SN=1641, FN=0, Flags=........C, BI=100, SSID="SERGIO_EXT"
    336 3.712830 TexasInstrum_12:4a:66 802.11 29 Clear-to-send, Flags=........C
    337 3.717555 1d:1d:1d:1d:1d:1d 0x1d1d 802.11 815 PV1 Extension (currently reserved)
    338 3.718139 1d:1d:1d:1d:1d:1d 0x1d1d 802.11 815 PV1 Extension (currently reserved)
    339 3.718652 1d:1d:1d:1d:1d:1d 0x1d1d 802.11 815 PV1 Extension (currently reserved)
    340 3.719185 1d:1d:1d:1d:1d:1d 0x1d1d 802.11 815 PV1 Extension (currently reserved)
    341 3.719739 1d:1d:1d:1d:1d:1d 0x1d1d 802.11 815 PV1 Extension (currently reserved)
    342 3.720267 1d:1d:1d:1d:1d:1d 0x1d1d 802.11 815 PV1 Extension (currently reserved)
    343 3.720805 1d:1d:1d:1d:1d:1d 0x1d1d 802.11 815 PV1 Extension (currently reserved)
    344 3.721222 1d:1d:1d:1d:1d:1d 0x1d1d 802.11 815 PV1 Extension (currently reserved)
    345 3.722660 1d:1d:1d:1d:1d:1d 0x1d1d 802.11 1415 PV1 Extension (currently reserved)
    346 3.724658 1d:1d:1d:1d:1d:1d 0x1d1d 802.11 1415 PV1 Extension (currently reserved)
    347 3.726338 1d:1d:1d:1d:1d:1d 0x1d1d 802.11 1415 PV1 Extension (currently reserved)
    348 3.728128 1d:1d:1d:1d:1d:1d 0x1d1d 802.11 1415 PV1 Extension (currently reserved)
    349 3.730221 1d:1d:1d:1d:1d:1d 0x1d1d 802.11 1415 PV1 Extension (currently reserved)
    350 3.732064 1d:1d:1d:1d:1d:1d 0x1d1d 802.11 1415 PV1 Extension (currently reserved)
    351 3.733923 1d:1d:1d:1d:1d:1d 0x1d1d 802.11 1415 PV1 Extension (currently reserved)
    352 3.735657 1d:1d:1d:1d:1d:1d 0x1d1d 802.11 1415 PV1 Extension (currently reserved)
    353 3.740973 TexasInstrum_12:4a:66 TpLinkTechno_df:08:df 802.11 136 Probe Request, SN=0, FN=0, Flags=........C, SSID="SERGIO_EXT"[Malformed Packet]

  • Hi,

    As Andres mentioned, it does not break anything and the chip still works but it is strange, I agree.

    Can you share the wireshark sniffer?

    Shlomi

  • Hi Shlomi.

    I'm sending you the Wi-Fi sniffer capture showing the spurious packets. They consistently originate after the CC3351 receives the CTS (frame 12).

    It's important to note that the issue never occurs after the CC3351 has successfully associated with the network. The behavior is consistently observed across different AP chipsets, but only during the association process. If the CC3351 is powered off the spurious packets no longer appear.

    Regards.

    Sergio

    Captura paquete espurio.zip