CC1312R7: TI network stack receives incorrect 802.15.4 frames from Contiki-NG

o s

Part Number: CC1312R7
Other Parts Discussed in Thread: , CC1312R, TIMAC

The TI network stack receives incorrect frame headers from Contiki-NG, preventing communication.

See the two attached pictures (.pcap files available on request) for the exact *same* radio frame.

First is the correct expected frame, from a device running contiki-NG, captured with latest sensniff from the Contiki-NG distribution.

Second is the incorrect frame capture, of the same frame from the same device running contiki-NG, but captured with SmartRF.

The TI SmartRF Packet Sniffer, running the TI 802.15.4 2 1.10 receives a completely bogus frame header, preventing higher level protocol decoding and decrypting the packet.
Note for clarity only one frame is included below, but *all frames are incorrect* from Contiki-NG.
Frames from TI networks stacks (not Contiki-NG) running on CC1312R7 appear to be correctly received in SmartRF Packet Sniffer.

Note that in both cases the *FCS is correct* indicating that all bits have been received correctly.
Smart RF Packet Sniffer settings attached for reference.

Any ideas of where the bug is?
Can we fix or workaround the bug ourselves or does TI/Contiki have to fix it?

11 months ago

0 Arthur R☑️ 11 months ago

TI__Genius 16206 points

Hi o s,

We are looking at it, but have you actually tried to receive frames on another device, or have you just used the Packet Sniffer?

Regards,

Arthur

0 o s 11 months ago in reply to Arthur R☑️

Prodigy 180 points

Hi Arthur,

Yes, the issue is that we are not receiving frames from Contiki-NG on our nodes. (And vice versa)
That is why we started looking at it in the packet sniffer.

Regards

Ola

0 o s 11 months ago

Prodigy 180 points

The TI capture is running on LP-CC1312R7, and the Contiki-NG capture on LP-CC1312R1 (as R7 is not supported out of the box)
Here are the custom radio params for Contiki-NG, in case any of this is of interest.

# Channel configuration
DEFINES += DOT_15_4G_CONF_FREQ_BAND_ID=DOT_15_4G_FREQ_BAND_CUSTOM
DEFINES += DOT_15_4G_CHAN_MIN=0
DEFINES += DOT_15_4G_CHAN_MAX=150
DEFINES += DOT_15_4G_FREQ_SPACING=350
DEFINES += DOT_15_4G_CHAN0_FREQ=868300
DEFINES += PROP_MODE_CONF_LO_DIVIDER=0x05
DEFINES += PROP_MODE_CONF_CENTER_FREQ=0x0387
DEFINES += IEEE802154_CONF_DEFAULT_CHANNEL=0

0 Arthur R☑️ 11 months ago in reply to o s

TI__Genius 16206 points

Hi o s,

What happens, capture wise when you select that PHY in Smart RF Packet sniffer?

Regards,

Arthur

0 Arthur R☑️ 11 months ago in reply to Arthur R☑️

TI__Genius 16206 points

The reason I am asking is that it seems like radio settings from https://github.com/contiki-ng/contiki-ng/blob/df0a157b2335ff9c3bfd40052edf66b8a1cb2c2b/arch/cpu/simplelink-cc13xx-cc26xx/rf-settings/cc13x2/prop-settings.c seem to match this.

0 o s 11 months ago in reply to Arthur R☑️

Prodigy 180 points

Hi Arthur,
Which version of the Sniffer Agent are you using?
We do not have the same options, see screenshot from the latest version downloaded: 1.10.0, Release date: 03 Feb 2023.
Also note the Contiki-NG radio settings above, it is running on 868.300 MHz
Regards
Ola

0 Arthur R☑️ 11 months ago in reply to o s

TI__Genius 16206 points

Hi Ola,

I use 1.10 as well, on the CC1312R, I do not understand why the setting might be different..

Can you delete all trace of Smart RF Packet Sniffer and reinstall it? Or confirm that you are indeed running the 1.10 version?

Regards,

Arthur

0 o s 11 months ago in reply to Arthur R☑️

Prodigy 180 points

Running the sniffer firmware on CC1312R7 gives the options I've posted above.
Running the sniffer firmware on CC1312R1 gives the option you've posted.
Is there some incompatiblity or firmware bug between CC1312R1 and R7?

0 o s 11 months ago in reply to Arthur R☑️

Prodigy 180 points

Running the CC1312R1 instead of R7 gives the options you've posted, but we get exactly the same bogus frames captured on R1 with the GSK50Kbps at 868.325 MHz.
See attached screenshot.
(We do get a few more FCS errors, not surprising since the receiver is off by 25 kHz)

0 Arthur R☑️ 11 months ago in reply to o s

TI__Genius 16206 points

Hi Ola,

Thanks for the captures, it does seems like we are missing the PHY option on the CC1312R7. I will notify the team in charge of that.

As of your actual issue, can you try the workaround outlined there? https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/998457/launchxl-cc1352r1-problem-with-sniffer-and-wireshark

I am looking at our issue tracking, and it seems like this is still not fixed...

Regards,

Arthur

0 o s 11 months ago in reply to Arthur R☑️

Prodigy 180 points

Hi, Yes I've already tried capturing with TIMAC 802.15.4GE capture format. It still gives bogus frames, albeit a bit different.
See attached capture. The destination address 0xFFFF is actually correct, but everything else is wrong.

0 Arthur R☑️ 11 months ago in reply to o s

TI__Genius 16206 points

Hi ola,

Looking at the contiki-ng github, it seems like they have not tested interoperability between the stacks, which leads to the following issue: https://github.com/contiki-ng/contiki-ng/issues/1369

I would think the ball is now on Contiki's court. It does seems to be on their roadmap.

Regards,

Arthur

0 o s 11 months ago in reply to Arthur R☑️

Prodigy 180 points

Thanks! Did not find this when googling. Yes, it does indeed look like a Contiki-NG bug.
(For obvious reasons I can't mark this as resolved until Contiki-NG fixes the issue, but it does seem that it is out of TI scope.)

Sub-1 GHz

Sub-1 GHz forum

CC1312R7: TI network stack receives incorrect 802.15.4 frames from Contiki-NG