Riot: cc2538: rf driver doesn't handle large packets

[LucaZulberti]

Hi all,

I've tried to ping a cc2538 based board with the gnrc_networking example:

ping6 -s 91 <link-local address>

and all it's ok, but if I try:

ping6 -s 92 <link-local address>

I don't receive any answer.

Output of "tcpdump -i wpan0" with correct echo reply:

11:22:21.846130 IEEE 802.15.4 Data packet seq 97 0023:00:12:4b:00:04:33:ee:f8 < 0023:07:06:05:04:03:02:01:00 
    0x0000:  7b33 3a80 00f1 6409 ad00 01fd e1a1 577b  {3:...d.......W{
    0x0010:  e80c 0008 090a 0b0c 0d0e 0f10 1112 1314  ................
    0x0020:  1516 1718 191a 1b1c 1d1e 1f20 2122 2324  ............!"#$
    0x0030:  2526 2728 292a 2b2c 2d2e 2f30 3132 3334  %&'()*+,-./01234
    0x0040:  3536 3738 393a 3b3c 3d3e 3f40 4142 4344  56789:;<=>?@ABCD
    0x0050:  4546 4748 494a 4b4c 4d4e 4f50 5152 5354  EFGHIJKLMNOPQRST
    0x0060:  5556 5758 595a                           UVWXYZ
11:22:21.860677 IEEE 802.15.4 Data packet seq d7 0023:07:06:05:04:03:02:01:00 < 0023:00:12:4b:00:04:33:ee:f8 
    0x0000:  7a33 3a81 00f0 6409 ad00 01fd e1a1 577b  z3:...d.......W{
    0x0010:  e80c 0008 090a 0b0c 0d0e 0f10 1112 1314  ................
    0x0020:  1516 1718 191a 1b1c 1d1e 1f20 2122 2324  ............!"#$
    0x0030:  2526 2728 292a 2b2c 2d2e 2f30 3132 3334  %&'()*+,-./01234
    0x0040:  3536 3738 393a 3b3c 3d3e 3f40 4142 4344  56789:;<=>?@ABCD
    0x0050:  4546 4748 494a 4b4c 4d4e 4f50 5152 5354  EFGHIJKLMNOPQRST
    0x0060:  5556 5758 595a                           UVWXYZ

Output of "tcpdump -i wpan0" without the right echo reply:

11:22:43.899244 IEEE 802.15.4 Data packet seq 9c 0023:00:12:4b:00:04:33:ee:f8 < 0023:07:06:05:04:03:02:01:00 
    0x0000:  7b33 3a80 0060 3709 af00 0113 e2a1 57f5  {3:..`7.......W.
    0x0010:  b70d 0008 090a 0b0c 0d0e 0f10 1112 1314  ................
    0x0020:  1516 1718 191a 1b1c 1d1e 1f20 2122 2324  ............!"#$
    0x0030:  2526 2728 292a 2b2c 2d2e 2f30 3132 3334  %&'()*+,-./01234
    0x0040:  3536 3738 393a 3b3c 3d3e 3f40 4142 4344  56789:;<=>?@ABCD
    0x0050:  4546 4748 494a 4b4c 4d4e 4f50 5152 5354  EFGHIJKLMNOPQRST
    0x0060:  5556 5758 595a 5b                        UVWXYZ[
11:22:43.911280 IEEE 802.15.4 Data packet seq dd 0023:07:06:05:04:03:02:01:00 < 0023:00:12:4b:00:04:33:ee:f8 
    0x0000:  e08c 000b 1050 5152 5354 5556 5758 595a  .....PQRSTUVWXYZ
    0x0010:  5b

With the samr21-xpro I can do:

ping6 -s 1000 <lladdr>

without problems.

Luca.

[miri64]

Might be, that the driver returns the wrong value for NETOPT_MAX_PACKET_SIZE.

[LucaZulberti]

The NETOPT_MAX_PACKET_SIZE is ok, the mtu is 127 byte.
A 6lowpan packet (max 1280 bytes) greater then 127 byte should be splitted in wpan packets of 127 bytes, am I missing anything?

[LucaZulberti]

This should not be done by the driver, but it happens only with the cc2538.

[miri64]

The maximum size of for packets _is_ done by the driver (some devices like the xbee e.g. are not able to send a full-sized IEEE 802.15.4 frames). The size should be 127 - mac header, so 127 is definitely too big (should be 102 IIRC)

[LucaZulberti]

Yes I understand what do you mean, the payload size of the cc2538 is 102 as the at86rf2xx one, but the 6lowpan standard defines the mtu at 1280, doesn't it? In fact it works for the at86rf2xx.

[miri64]

You are confusing MTU (on IP layer) with the maximum payload length of a radio frame right now ;-). 102 is the maximum payload length an IEEE 802.15.4 radio can send in a frame (at least in the configuration we run them). 1280 is the size an IPv6 packet over IEEE 802.15.4 can have _at maximum_.

But if it is the same as the at86rf2xx, it must be something else in communication with the device... The 6LoWPAN implementation is pretty loosely coupled to the device. Except address information (NETOPT_IPV6_IID, NETOPT_ADDRESS_LONG, NETOPT_SRC_LEN), information if the device is wired or a radio (NETOPT_IS_WIRED), and the demultiplexing type (NETOPT_PROTO), there is not much interaction with the device (except of course for sending/receiving data ;-)). Maybe comparing the results of these options can get you some information about what is going wrong.

[OlegHahm]

Just a pretty wild guess, but if the cc2538 driver cannot handle packets coming in rather quickly back to back, this could also lead to the mentioned problem.

_Edit_: should have read more carefully, receiving seems to work somehow, since the device _is_ responding.

[OlegHahm]

Anyway, enabling DEBUG in the radio driver might help to figure the root of the problem,

[LucaZulberti]

You are confusing MTU (on IP layer) with the maximum payload length of a radio frame right now ;-). 102 is the maximum payload length an IEEE 802.15.4 radio can send in a frame (at least in the configuration we run them). 1280 is the size an IPv6 packet over IEEE 802.15.4 can have at maximum.

Yes sorry, I said that badly.

But if it is the same as the at86rf2xx, it must be something else in communication with the device... The 6LoWPAN implementation is pretty loosely coupled to the device. Except address information (NETOPT_IPV6_IID, NETOPT_ADDRESS_LONG, NETOPT_SRC_LEN), information if the device is wired or a radio (NETOPT_IS_WIRED), and the demultiplexing type (NETOPT_PROTO), there is not much interaction with the device (except of course for sending/receiving data ;-)). Maybe comparing the results of these options can get you some information about what is going wrong.

I will do some tests. Thank you a lot.

Anyway, enabling DEBUG in the radio driver might help to figure the root of the problem

Ok! I will post the results in the next days.

[aeneby]

I will need to look at this more closely when I get time, but I suspect that @OlegHahm is correct - it's probably because the driver does not handle multiple frames in the RX FIFO.

[aeneby]

The error you describe above is actually caused by the driver tripping over it's own feet trying to respond to the ping - the ping query is received okay, but it doesn't wait for the first reply packet to finish sending before attempting to send the second one. This issue is described (and addressed) more fully in #5725.

You'll still hit the RX FIFO problem described above, though, once you increase the ping payload enough (at least ~177 bytes). This is a little trickier to handle since we need to deal with multiple packets arriving in the RX FIFO.

[LucaZulberti]

Sorry, but I thought this has been resolved by #5803...

I have tested with that PR, I can't ping with large packets.
I have enabled debug of the "netapi", but there aren't messages of dropped packets.

[miri64]

Even if that would fix it, the normal workflow would be to close the issue _after_ the fix was merged to master ;-)

[LucaZulberti]

Received, I'm sorry.

[miri64]

No problem :-)

[aeneby]

@LucaZulberti are you able to test whether this issue still exists in master?

[LucaZulberti]

@aeneby Sure, I can test this, but not before Thursday.

Il 10 Ottobre 2016 23:07:34 CEST, Aaron Sowry [email protected] ha scritto:

@LucaZulberti are you able to test whether this issue still exists in
master?

You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/RIOT-OS/RIOT/issues/5719#issuecomment-252746596

[LucaZulberti]

Tested... This issue still exists.

[PeterKietzmann]

@LucaZulberti, @alignan within the scope of release testings I pinged with large packets between remote-revb and phytec boards as well as remote-reva and samr21-xpro boards and had great success regarding error rates. Could you check if this issue still persists please?

[LucaZulberti]

Hi Peter, I've flashed the gnrc_networking example on a CC2538 based board and a samr21-xpro board.
I pinged with different size of packets (100, 200, 400, 800) and I had great success too! Thanks to developers!

[PeterKietzmann]

Great! Thanks for testing again.