sys/udp: Checksum calculation broken

[fnack]

UDP packet handling no longer works because the checksum calculation in udp.c fails. Reverting in the master history, the problem was introduced with the merge of #2497.

The problem can for example be reproduced using the rpl_udp example:
Sending:

send fe80::ff:fe00:afee hello
Successful deliverd 28 bytes over UDP to ff02::1 to 6LoWPAN

But on the receiver side it fails:

IPv6 datagram received (next header: 11) from fe80::200:ff:fe00:afee
Wrong checksum (2)!

[fnack]

@gebart: I assigned you because I think the problem was invented with your pull request #2497. Unfortunately, I don't have the time to look deeply into the problem myself. I would appreciate if you could come up with a fix because this is a show-stopper.

[fnack]

Maybe @authmillenon is also interested in this issue?

[jnohlgard]

@fnack can you provide a packet capture? The source address is wrong on the receiving end, which gives the wrong checksum (2), we need to check whether the error is in the reception or transmission

[cgundogan]

Interesting.. when I test rpl_udp on native I do not see any checksum errors from udp. However, as a side effect form the bug I mentioned in #2493 it is not possible to send messages from root -> node, because DAOs are not received properly by root.

[fnack]

A packet capture in libpcap format from wireshark can be found here.

Ifconfig on sender:

Iface   0   HWaddr: 0xaa11 Channel: 0 PAN ID: 0xabcd
            EUI-64: 00-00-00-ff-fe-00-aa-11
            Source address mode: short
            Transceivers:
             * native
            inet6 addr: fe80::ff:fe00:aa11/128  scope: local
            inet6 addr: ff02::1:ff00:aa11/128  scope: local [multicast]
            inet6 addr: ff02::1/128  scope: local [multicast]
            inet6 addr: ::1/128  scope: global
            inet6 addr: ff02::1:ff00:1/128  scope: local [multicast]
            inet6 addr: ff02::1a/128  scope: local [multicast]
            inet6 addr: abcd::ff:fe00:aa11/128  scope: global
            inet6 addr: ff02::2/128  scope: local [multicast]

Ifconfig on receiver:

Iface   0   HWaddr: 0x40ed Channel: 0 PAN ID: 0xabcd
            EUI-64: 00-00-00-ff-fe-00-40-ed
            Source address mode: short
            Transceivers:
             * native
            inet6 addr: fe80::ff:fe00:40ed/128  scope: local
            inet6 addr: ff02::1:ff00:40ed/128  scope: local [multicast]
            inet6 addr: ff02::1/128  scope: local [multicast]
            inet6 addr: ::1/128  scope: global
            inet6 addr: ff02::1:ff00:1/128  scope: local [multicast]
            inet6 addr: ff02::1a/128  scope: local [multicast]
            inet6 addr: abcd::ff:fe00:40ed/128  scope: global
            inet6 addr: ff02::2/128  scope: local [multicast]

The corresponding output is:

send fe80:ff:fe00:40ed helloo
Successful deliverd 28 bytes over UDP to ff02::1 to 6LoWPAN

Receiver:

IPv6 datagram received (next header: 11) from fe80::200:ff:fe00:aa11
Wrong checksum (2)!

I'm confused where the 200 in the printed source address on the receiver side comes from.

EDIT: All data from rpl_udp example tested with native on current master.

[cgundogan]

@fnack the 200 comes from the flipping of the universal/local bit when generating the link local address from the EUI-64. see here https://tools.ietf.org/html/rfc4291#page-20

[jnohlgard]

I think we need to revise the EUI-64 generation. I can't find a authoritative source on how to generate 64 bit addresses from 16 bit short 802.15.4 address. I have the following PPT which suggests using PAN ID and Short address to create a 64 bit address.
http://solomon.ipv6.club.tw/Course/ProtocolEngineering/20100505-liwen-rfc4944.ppt

[cgundogan]

I was also searching for the past hour.. and did also not find any specific source. What I found so far:

• https://tools.ietf.org/html/rfc4944#section-6

  All 802.15.4 devices have an IEEE EUI-64 address, but 16-bit short
  addresses (Section 3 and Section 12) are also possible. In these
  cases, a "pseudo 48-bit address" is formed as follows. First, the
  left-most 32 bits are formed by concatenating 16 zero bits to the 16-
  bit PAN ID (alternatively, if no PAN ID is known, 16 zero bits may be
  used). This produces a 32-bit field as follows:
  16_bit_PAN:16_zero_bits
  Then, these 32 bits are concatenated with the 16-bit short address.
  This produces a 48-bit address as follows:
  32_bits_as_specified_previously:16_bit_short_address
  The interface identifier is formed from this 48-bit address as per
  the "IPv6 over Ethernet" specification [RFC2464]. However, in the
  resultant interface identifier, the "Universal/Local" (U/L) bit SHALL
  be set to zero in keeping with the fact that this is not a globally
  unique value. For either address format, all zero addresses MUST NOT
  be used.

• https://tools.ietf.org/html/rfc6282#section-3.2.2

  A short IEEE 802.15.4 address is 16 bits in length. Short addresses
  are mapped into the restricted space of IEEE EUI-64 addresses by
  setting the middle 16 bits to 0xfffe, the bottom 16 bits to the short
  address, and all other bits to zero. As a result, an IID generated
  from a short address has the form:
  0000:00ff:fe00:XXXX
  where XXXX carries the short address. The universal/local bit is
  zero to indicate local scope.

[cgundogan]

it confuses me that RFC4944 suggests using the PAN-ID as a prefix (if available), but there is no word of that PAN-ID in RFC6282..
On the other hand, RFC6282 is meant as an update for RFC4944 ..

[cgundogan]

While RFC4944 states that the u/l bit SHALL be set to zero, RFC6282 just tells

The universal/local bit is zero to indicate local scope.

But I cannot find any MUST or SHALL in this context..

[jnohlgard]

I vote for going with RFC4944 and generating a 48 bit "ethernet MAC" from the PAN and short addr, and handling it like a 48 bit address and inserting 0xfffe in the middle. Thoughts on this?

[cgundogan]

what about the u/l bit? how should this be handled when deriving the IID from the short address?

[cgundogan]

semantically, I would prefer to leave the u/l bit as zero to point out that this interface id is not universally unique, but generated from an arbitrary short address

[jnohlgard]

@cgundogan I agree. Set the U/L to 1 in the "MAC" address to signify a local address, then it will be inverted in the EUI-64 to IID conversion as recommended by the RFC when used in 6lowpan.

[cgundogan]

👍 sound.
So to sum it up:
To create link-local addresses from

1. EUI-64 addresses => flip the u/l bit and prepend the fe80::/64 prefix
2. short address => generate the MAC-address [1] and set the u/l bit to 1 (local scope), put the 0xfffe in the middle, then do step 1.

[1] 16_bit_PAN:16_zero_bits:16_bit_short_address

[jnohlgard]

@cgundogan That's a good description of what I was thinking.

[jnohlgard]

@cgundogan Do you have the time to implement the proposed algorithm soon-ish?

[cgundogan]

I will have a look at it asap

[cgundogan]

@fnack it's a long shot, but can you try #2517 and see if it helps with your issue?

[miri64]

I vote for going with RFC4944 and generating a 48 bit "ethernet MAC" from the PAN and short addr, and handling it like a 48 bit address and inserting 0xfffe in the middle. Thoughts on this?

That is the complete opposite to what we decided in the NSTF on. We decided on the RFC6282 solution since it is the update. All in all: the EUI-64 from 16-bit address generation is not standardized globally and a totally 6LoWPAN-related thing. This is why I think (after 2 years of working with this) it's a bad idea to put this stuff in the link-layer anyways. ;-)

[fnack]

Just checked #2517 and #2518. For both PR's the problem seems to be fixed.

[jnohlgard]

I think I will be able to participate remotely in the hack N ack tomorrow, maybe we'll be able to solve this during that time?

[cgundogan]

@gebart good idea, I also will most likely attend

[jnohlgard]

@authmillenon I trust in your experience in this field. Does the ng-net implementation of the network layer know about link-layer properties such as PAN IDs and such?
How are other 802.15.4 implementations doing this?

I suggest that in using short addresses, the U/L bit should be set to 1, example:
short address: 0x1234
EUI-64: 02-00-00-ff-fe-00-12-34
Link-local IPv6: fe80::ff:fe00:1234

This follows the guideline to invert the bit when taking the EUI address as an IPv6 link local address, which means that it does not need any branching in the IPHC/lowpan handler for different kinds of hardware addresses.

[jnohlgard]

Is there any benefit to including the PAN ID in the link-local address? The overlap between the RFC 4944 PAN ID bits and the U/L bit makes the choice of inverting/non-inverting seem arbitrary and probably won't play well with other implementations..

[jnohlgard]

For what it's worth, Wireshark agrees that the IEEE802.15.4 packet sent from short address 0x2615 with IPHC mode source address elided (0 bits), has a decompressed IPv6 source address of fe80::ff:fe00:2615

https://www.cloudshark.org/captures/3751f069fe12

I forged that packet by hand btw, I don't have a PR yet.

[jnohlgard]

Closed via #2523