6lo uncompress_IPHC_header overwrites IPHC fields

zephyrbot commented 7 years ago

Reported by Johann Fischer:

/subsys/net/ip/6lo.c : inside uncompress_IPHC_header:

The IPHC field will be gradually overwritten, first at the line {code:java} ipv6 = (struct net_ipv6_hdr *)(frag->data); {code}

The uncompression logic is broken.

Trapped with: {code:java} diff --git a/subsys/net/ip/6lo.c b/subsys/net/ip/6lo.c index 9c93660df..27838aaf1 100644 --- a/subsys/net/ip/6lo.c +++ b/subsys/net/ip/6lo.c @@ -1282,13 +1282,19 @@ static inline bool uncompress_IPHC_header(struct net_buf *buf)

    ipv6 = (struct net_ipv6_hdr *)(frag->data);

NET_DBG("1: CIPHC[0] 0x%x, CIPHC[1] 0x%x", CIPHC[0], CIPHC[1]);

/* Version is always 6 */
ipv6->vtc = 0x60;
net_nbuf_set_ip_hdr_len(buf, NET_IPV6H_LEN);

NET_DBG("2: CIPHC[0] 0x%x, CIPHC[1] 0x%x", CIPHC[0], CIPHC[1]);

/* Uncompress Traffic class and Flow label */
offset = uncompress_tfl(buf, ipv6, offset);

NET_DBG("3: CIPHC[0] 0x%x, CIPHC[1] 0x%x", CIPHC[0], CIPHC[1]);

if (!(CIPHC[0] & NET_6LO_IPHC_NH_1)) {
        ipv6->nexthdr = CIPHC[offset];
        offset++;

{code}

Log output: [net/ieee802154] [DBG] validate_fc_seq: (0x20002770): fs: 1/0/0/0/1/0/0/0/2/1/3 - 0 [net/ieee802154] [DBG] validate_addr: (0x20002770): Buf 0x20003233 - mode 2 - pan id comp 0 [net/ieee802154] [DBG] validate_addr: (0x20002770): Buf 0x20003237 - mode 3 - pan id comp 1 [net/ieee802154] [DBG] validate_payload_and_mfr: (0x20002770): Header size: 15, vs total length 48: payload size 31 [net/nbuf] [DBG] net_nbuf_get_reserve_debug: (0x20002770): DATA [9] buf 0x20003218 reserve 15 ref 1 (uncompress_IPHC_header():1278) [net/6lo] [DBG] uncompress_IPHC_header: (0x20002770): 1: CIPHC[0] 0x7b, CIPHC[1] 0x49 [net/6lo] [DBG] uncompress_IPHC_header: (0x20002770): 2: CIPHC[0] 0x60, CIPHC[1] 0x49 [net/6lo] [DBG] uncompress_tfl: (0x20002770): ECN + DSCP + 4-bit Pad + Flow Label [net/6lo] [DBG] uncompress_IPHC_header: (0x20002770): 3: CIPHC[0] 0x6e, CIPHC[1] 0x82 [net/6lo] [DBG] uncompress_sa: (0x20002770): SAC_0 [net/6lo] [DBG] uncompress_sa: (0x20002770): SAM_00 full src addr inlined [net/6lo] [DBG] uncompress_da: (0x20002770): DAC_0 [net/6lo] [DBG] uncompress_da: (0x20002770): DAM_10 dst addr 16 bit compressed [net/6lo] [DBG] uncompress_nh_udp: (0x20002770): src 8 bits, dst full inlined [net/6lo] [DBG] uncompress_IPHC_header: (0x20002770): Removing 28 bytes of compressed hdr [net/nbuf] [DBG] net_nbuf_compact: (0x20002770): Compacting data to buf 0x20003218 [net/utils] [DBG] net_calc_chksum: (0x20002770): Unknown protocol family 0 [net/core] [DBG] process_data: (0x20002770): Unknown IP family packet (0x0) [net/core] [DBG] processing_data: (0x20002770): Dropping buf 0x20002c20

packet dump: (Neighbor Solicitation for fe80::2092:1fff:5584:fdb5) 0000 00 03 03 25 00 00 00 00 00 00 00 00 00 00 00 f6 0010 41 d8 00 00 00 ff ff b5 fd 84 55 ff 1f 92 22 7b 0020 49 3a 02 01 ff 84 fd b5 87 00 ea 21 00 00 00 00 0030 fe 80 00 00 00 00 00 00 20 92 1f ff 55 84 fd b5 0040 5a fb

(Imported from Jira ZEP-1564)

zephyrbot commented 7 years ago

by Ravi kumar Veeramally:

Can you provide original packet dump without compression. I will verify with 6lowpan unit tests.

zephyrbot commented 7 years ago

by Johann Fischer:

Probably not, the package was sent by another node over 6lo (running zephyr).

I'm not so deep in net_buf, after {code:java} frag = net_nbuf_get_reserve_data(net_nbuf_ll_reserve(buf)); {code}

frag->data and ((buf->frags)->data) point to the same address:

(gdb) print /x *frag                                                                                     
$9 = {{_unused = 0x0, frags = 0x0}, sent_list = {next = 0xeba011f1}, ref = 0x1, flags = 0x0,
  pool = 0x2000006c, {{data = 0x20002c8f, len = 0x0, size = 0x7d}, b = {data = 0x20002c8f, len = 0x0,
      size = 0x7d, __buf = 0x20002c80 <_net_buf_pool_data_buffers+176>}},
  __buf = 0x20002c80 <_net_buf_pool_data_buffers+176>}
(gdb) print /x ((buf->frags)->data)
$10 = 0x20002c8f
(gdb) print /x buf->data
$11 = 0x20002838
(gdb)

Log output: [net/nbuf] [DBG] net_nbuf_get_reserve_debug: (0x20002770): DATA [9] buf 0x20003218 reserve 15 ref 1 (uncompress_IPHC_header():1278)

Is there something wrong with net_nbuf_get_reserve_data?

zephyrbot commented 7 years ago

by Ravi kumar Veeramally:

Actually it shouldn't be same (frag->data and ((buf->frags)->data)). I will investigate it.

zephyrbot commented 7 years ago

by Ravi kumar Veeramally:

I couldn't reproduce with unit tests, seems no problem with 6lo uncompress logic. Can you provide complete test setup and samples (if any) ?.

zephyrbot commented 7 years ago

by Johann Fischer:

I test it with FRDM-K64F board and MCR20A driver (9807), I see still other errors all somehow related to net_buf. Can be that it only concerns this platform. I take time and dig a little deeper. thx

zephyrbot commented 7 years ago

by Ravi kumar Veeramally:

NET_BUF_LOG and NET_DEBUG_NET_BUF might helpful to you.

zephyrbot commented 7 years ago

by Ravi kumar Veeramally:

Any updates?

zephyrbot commented 7 years ago

by Johann Fischer:

I've found a bug in my driver, echo_client over 6lo is still unstable, but this error does not occur anymore, thx and sorry for the noise.

zephyrbot commented 7 years ago

by Ravi kumar Veeramally:

No problem, close this issue and file a new jira entry if you come across any issue.

zephyrbot commented 7 years ago

by Mark Linkmeyer:

Fixing incorrect priority

zephyrproject-rtos / zephyr

6lo uncompress_IPHC_header overwrites IPHC fields #3028