net_if: proper u/l-bit inversion for short addresses #2518
Conversation
cgundogan
added
Type: bug
|
@authmillenon @gebart please look at this alternative |
| @@ -122,7 +122,7 @@ void udp_send(int argc, char **argv) | |||
| memset(&sa, 0, sizeof(sa)); | |||
|
|
|||
| if (address) { | |||
| ipv6_addr_init(&ipaddr, 0xabcd, 0x0, 0x0, 0x0, 0x0, 0x00ff, 0xfe00, (uint16_t)address); | |||
| ipv6_addr_init(&ipaddr, 0xabcd, 0x0, 0x0, 0x0, 0x0200, 0x00ff, 0xfe00, (uint16_t)address); | |||
There was a problem hiding this comment.
Why is this happening in UDP? IP chooses the best fitting source address. Also s/0xabcd/0x0000/ as it is done everywhere else.
There was a problem hiding this comment.
well somehow you have to define the destination address to the socket, before going down to ip
There was a problem hiding this comment.
but the setting of abcd explains a lot, why we have so many checksum errors with UDP. Why abcd? Even if we use the method in RFC 4944, who is saying that the PAN is abcd for the destination?
There was a problem hiding this comment.
I don't think abcd is representing the pan id here. The device is configured with an ip address prefixed with abcd in rpl_udp/rpl.c . that's why the destination address also has to start with abcd
cgundogan
added
the
CI: needs squashing
|
I updated this to prevent u/l inversion for short addresses. |
| @@ -1295,9 +1295,6 @@ void lowpan_iphc_decoding(uint8_t *data, uint8_t length, net_if_eui64_t *s_addr, | |||
| memcpy(&(ipv6_buf->srcaddr.uint8[0]), &ll_prefix[0], 2); | |||
| memset(&(ipv6_buf->srcaddr.uint8[2]), 0, 6); | |||
| memcpy(&(ipv6_buf->srcaddr.uint8[8]), &s_addr->uint8[0], 8); | |||
| /* Invert Universal/local bit as specified in | |||
| * RFC4291, section 2.5.1 "Interface Identifiers" */ | |||
| ipv6_buf->srcaddr.uint8[8] ^= 0x02; | |||
There was a problem hiding this comment.
@gebart Without these two lines the example works on native again.. but I fear this undoes your PR introducing the u/l bit inversion.. Can you test this on your setup?
There was a problem hiding this comment.
I don't have any time to test this right now, but I guess it would work again since it reverts the change in #2497
|
The IPHC en-/decoding will also need to handle short addresses differently in order for it to work. If we always "translate" short addresses to extended and flipping the annoying bit (new name, same old 0x02) I guess it would work. It may cause troubles in other parts using the hardware address though.. |
|
@cgundogan please test #2499 again, I have added two more commits for EUI64 handling for short addresses. |
|
Sorry, I split the PR, please test #2523 instead. |
|
Can this be closed now that #2523 has been merged? |
|
@gebart ofcourse, I will close this one |
This is an alternative to #2517 and does not introduce the pan_id to the IID/EUI-64 generation from short addresses