cc1310 - can't receive fragmented TCP packet

[filug]

Hi,

Environment

I'm using two CC1310 radios:

• first radio is working as a slip radio and it is connected to the native-border-router,
• second is working as wget app

Slip radio is working with the following configuration

Starting Contiki-3.x-3055-gac2a314
With DriverLib v0.47020
TI SmartRF06EB + CC13xx EM
IEEE 802.15.4: No, Sub-GHz: Yes, BLE: No, Prop: No
Packet from TUN of length 2 - write SLIP
 Net: slipnet
 MAC: nullmac
 RDC: nullrdc
 RF: Channel 25
 Node ID: 17313

and on PC side it's connected to the native border router as presented below

sudo ./border-router.native -B 115200 -t tun3 -s /dev/ttyUSB2 -v3  aaaa::1/64

This wget enabled endnode is using following configuration

Starting Contiki-3.x-3055-gac2a314
With DriverLib v0.47020
TI CC1310 LaunchPad
IEEE 802.15.4: No, Sub-GHz: Yes, BLE: No, Prop: No
 Net: sicslowpan
 MAC: CSMA
 RDC: nullrdc
 RF: Channel 25
 Node ID: 57547

Background

With configuration above I'm able to:

• reach local router web page http://[aaaa::212:4b00:a29:43a1]/ from my PC,
• download this same page via wget endnode (by wget http://[aaaa::212:4b00:a29:43a1] command)

Error

On my PC I have also lighttpd server and from this server I'm trying via wget http://[aaaa::1]/foo.file download some file (for this test file is 17 bytes long).

Unfortunately during this step it seems that slip radio and wget endnode are not able to cooperate together. On wget endode I see

Host aaaa::1
File /foo.file
Connecting...
In tcp_send
Sending TCP packet to aaaa::1 from aaaa::212:4b00:e07:e0cb
Upper layer checksum len: 24 from: 40
Sending packet with length 64 (24)
tcpip_ipv6_output: no route found, using default route
sicslowpan output: sending packet len 72
before compression (32): 6000000000200040aaaa00000000000002124b000e07e0cbaaaa000000000000000000000000000106006304001e013e04010050000000000000000060020080074f000002040080
sicslowpan output: header of len 35
sicslowpan input: IPHC
IPHC: next header inline: 0
Uncompressing 0 + 16 => aaaa::1
Uncompressing 0 + 16 => aaaa::212:4b00:e07:e0cb
sicslowpan input: IP packet ready (length 72)
after decompression 32:600bdeda0020003faaaa0000000000000000000000000001aaaa00000000000002124b000e07e0cb06006304801e0080005004014909d610000000016012708073030000020405a0
IPv6 packet received from aaaa::1 to aaaa::212:4b00:e07:e0cb
Processing RPL option
Cutting ext-header before processing (extlen: 8, uiplen: 72)
Receiving TCP packet
Upper layer checksum len: 24 from: 40
In found
connected
In tcp_send
Sending TCP packet to aaaa::1 from aaaa::212:4b00:e07:e0cb
Upper layer checksum len: 138 from: 40
Sending packet with length 178 (138)
tcpip_ipv6_output: no route found, using default route
sicslowpan output: sending packet len 186
before compression (146): 6000000000920040aaaa00000000000002124b000e07e0cbaaaa000000000000000000000000000106006304001e013e04010050000000014909d611501800806f200000474554202f666f6f2e66696c6520485454502f312e300d0a486f73743a205b616161613a3aa
sicslowpan output: header of len 35
uip_len: 186, fragments: 2, free bufs: 7
Fragmentation sending packet len 186
sicslowpan output: 1rst fragment (len 64, tag 0)
sicslowpan output: fragment (offset 13, len 82, tag 0)
sicslowpan input: IPHC
IPHC: next header inline: 0
Uncompressing 0 + 16 => aaaa::1
Uncompressing 0 + 16 => aaaa::212:4b00:e07:e0cb
sicslowpan input: IP packet ready (length 68)
after decompression 28:600bdeda001c003faaaa0000000000000000000000000001aaaa00000000000002124b000e07e0cb06006304801e0080005004014909d61100000077501070808a360000
IPv6 packet received from aaaa::1 to aaaa::212:4b00:e07:e0cb
Processing RPL option
Cutting ext-header before processing (extlen: 8, uiplen: 68)
Receiving TCP packet
Upper layer checksum len: 20 from: 40
In found
sicslowpan input: FRAG1 size 196, tag 0, offset 0)
sicslowpan input: IPHC
IPHC: next header inline: 0
Uncompressing 0 + 16 => aaaa::1
Uncompressing 0 + 16 => aaaa::212:4b00:e07:e0cb
sicslowpan input: unknown dispatch: 0
sicslowpan input: IPHC
IPHC: next header inline: 58
Uncompressing 2 + 0 => fe80::212:4b00:a29:43a1
Uncompressing 2 + 1 => ff02::1a
sicslowpan input: IP packet ready (length 116)
after decompression 76:60000000004c3a40fe8000000000000002124b000a2943a1ff02000000000000000000000000001a9b014e8f1ef0008010f30000aaaa00000000000002124b000a2943a1040e00080c0a038000800001001e003c081e4040000000000000000000000000aaaa0000000000
IPv6 packet received from fe80::212:4b00:a29:43a1 to ff02::1a
icmp6_input: length 116 type: 155 
Upper layer checksum len: 76 from: 40
sicslowpan input: FRAG1 size 196, tag 1, offset 0)
sicslowpan input: IPHC
IPHC: next header inline: 0
Uncompressing 0 + 16 => aaaa::1
Uncompressing 0 + 16 => aaaa::212:4b00:e07:e0cb
sicslowpan input: FRAGN size 196, tag 1, offset 24)
last_fragment?: packetbuf_payload_len 4 frag_size 196
Fragsize: 4
Upper layer checksum len: 76 from: 40
sicslowpan output: sending packet len 116
before compression (76): 60000000004c3a40fe8000000000000002124b000e07e0cbff02000000000000000000000000001a9b01ad071ef0010010f20000aaaa00000000000002124b000a2943a1040e00080c0a038000800001001e003c081e4040000000000000000000000000aaaa00000000
sicslowpan output: header of len 4
sicslowpan input: FRAG1 size 196, tag 2, offset 0)
sicslowpan input: IPHC
IPHC: next header inline: 0
Uncompressing 0 + 16 => aaaa::1
Uncompressing 0 + 16 => aaaa::212:4b00:e07:e0cb
sicslowpan input: unknown dispatch: 0
sicslowpan input: FRAGN size 196, tag 2, offset 24)
last_fragment?: packetbuf_payload_len 4 frag_size 196
Fragsize: 4

If I understand correctly sicslowpan input: unknown dispatch: 0 can be caused by broken RX frame.

Comparing Wireshark logs and border router with increased verbosity (to -v5) I see that packets from lighttpd are divided into several separate chunks

Packet from SLIP of length 2 - write TUN
0000 00 01
Packet input over SLIP: 2
Packet from TUN of length 108 - write SLIP
0000 21 53 0d 03 0a 00 36 0b 00 01 0e 00 01 41 d8 36 cd ab ff ff a1 43 29 0a 00 4b 12 00 7a 3b 3a 1a 9b 01 4e 90 1e f0 00 80 10 f2 00 00 aa aa 00 00 00 00 00 00 02 12 4b 00 0a 29 43 a1 04 0e 00 08 0c 0a 03 80 00 80 00 01 00 1e 00 3c 08 1e 40 40 00 00 00 00 00 00 00 00 00 00 00 00 aa aa 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Packet from TUN of length 133 - write SLIP
0000 21 53 0e 03 0a 00 37 0b 00 01 0e 00 01 61 dc 37 cd ab cb e0 07 0e 00 4b 12 00 a1 43 29 0a 00 4b 12 00 c0 c4 00 03 68 00 0f 65 26 00 3f aa aa 00 00 00 00 00 00 00 00 00 00 00 00 00 01 aa aa 00 00 00 00 00 00 02 12 4b 00 0e 07 e0 cb 06 00 63 04 80 1e 00 80 00 50 04 02 08 47 ce f4 00 00 00 db 50 18 70 80 1b 0b 00 00 48 54 54 50 2f 31 2e 30 20 32 30 30 20 4f 4b 0d 0a 43 6f 6e 74 65 6e 74 2d 54 79 70
Packet from TUN of length 135 - write SLIP
0000 21 53 0f 03 0a 00 38 0b 00 01 0e 00 01 61 dc 38 cd ab cb e0 07 0e 00 4b 12 00 a1 43 29 0a 00 4b 12 00 e0 c4 00 03 0c 65 3a 20 61 70 70 6c 69 63 61 74 69 6f 6e 2f 6f 63 74 65 74 2d 73 74 72 65 61 6d 0d 0a 41 63 63 65 70 74 2d 52 61 6e 67 65 73 3a 20 62 79 74 65 73 0d 0a 43 6f 6e 74 65 6e 74 2d 4c 65 6e 67 74 68 3a 20 31 37 0d 0a 43 6f 6e 6e 65 63 74 69 6f 6e 3a 20 63 6c 6f 73 65 0d 0a 44 61 74 65 3a 20
Packet from TUN of length 43 - write SLIP
0000 21 53 00 03 0a 00 39 0b 00 01 0e 00 01 61 dc 39 cd ab cb e0 07 0e 00 4b 12 00 a1 43 29 0a 00 4b 12 00 e0 c4 00 03 18 57 65 64 2c
Packet from SLIP of length 74 - write TUN
0000 61 dc c9 cd ab a1 43 29 0a 00 4b 12 00 cb e0 07 0e 00 4b 12 00 7a 33 3a 9b 02 39 c4 1e 40 00 fe aa aa 00 00 00 00 00 00 02 12 4b 00 0a 29 43 a1 05 12 00 80 aa aa 00 00 00 00 00 00 02 12 4b 00 0e 07 e0 cb 06 04 00 00 00 1e
Packet input over SLIP: 74

For my further investigations I assumed (don't know if this assumption is correct) that "too fast" write SLIP commands are responsible for sicslowpan input: unknown dispatch: 0 error on wget endnode side. Is it possible that "too fast" native border router can force slip radio to send malformed TX radio packets?

To verify my assumption I've added one extra sleep to the slip-dev.c file (for native-border-router)

@@ -400,10 +400,11 @@ write_to_serial(int outfd, const uint8_t *inbuf, int len)
       break;
     }
   }
   slip_send(outfd, SLIP_END);
   PROGRESS("t");
+  sleep(1);
 }

and it helped.

sleep(1) is of course stupid workaround; does anybody can advice me how to solve this issue?

---

During mu investigations I've tested several bug fixes (like Increase number of PROP mode RX buffers to 4 or made by @g-oikonomou but still no luck.

[g-oikonomou]

Please see #1878 just in case you are looking at the same thing here.