6lo: RIOT does not receive packets from Linux when short_addr is set

[benpicco]

Description

When setting a short address on a Linux host (iwpan dev wpan0 set short_addr 0x2), RIOT is not able to receive packets send from that Linux host anymore.

A simple test is to use ICMP ping, but this can also be observed with UDP messages.

Steps to reproduce the issue

• obtain a Linux device with a 802.15.4 interface. I use a raspberry pi with a mrf24j40 module connected over SPI
• prepare a device with RIOT. I used the samr21-xpro with the gnrc_networking example
• (optional) prepare a device with Zephyr so we can have a majority vote as to who is right in handling the packets 😉 I use the nRF52840-PCA10056 with the net/sockets/echo_server example: mkcd build && cmake -DBOARD=nrf52840_pca10056 -DCONF_FILE="prj.conf overlay-802154.conf" ..

On Linux:

iwpan phy0 set channel 0 26
iwpan dev wpan0 set pan_id 0xabcd
iwpan dev wpan0 set short_addr 0x1 # remove this line and everything just works™

ip link add link wpan0 name lowpan0 type lowpan

ip link set wpan0 up
ip link set lowpan0 up

Observe that we now have a two lowpan0 interface with IP addresses attached to it:

$ ip addr show lowpan0
4: lowpan0@wpan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1280 qdisc noqueue state UNKNOWN group default qlen 1000
    link/6lowpan 1a:6a:33:b1:1b:a0:12:12 brd ff:ff:ff:ff:ff:ff:ff:ff
    inet6 fe80::a9cd:ff:fe00:1/64 scope link  # we only get this one if we set the short_addr
       valid_lft forever preferred_lft forever
    inet6 fe80::186a:33b1:1ba0:1212/64 scope link 
       valid_lft forever preferred_lft forever

On RIOT

ifconfig 7 set chan 26
ifconfig 7 set nid abcd
ifconfig 7 set addr_short 2

look at the resulting network configuration

2019-02-19 17:19:55,820 - INFO # Iface  7  HWaddr: 02:00  Channel: 26  Page: 0  NID: 0xabcd
2019-02-19 17:19:55,825 - INFO #           Long HWaddr: 79:7D:36:2C:C9:59:06:5A 
2019-02-19 17:19:55,832 - INFO #            TX-Power: 0dBm  State: IDLE  max. Retrans.: 3  CSMA Retries: 4 
2019-02-19 17:19:55,839 - INFO #           AUTOACK  ACK_REQ  CSMA  L2-PDU:102 MTU:1280  HL:64  RTR  
2019-02-19 17:19:55,840 - INFO #           6LO  IPHC  
2019-02-19 17:19:55,845 - INFO #           Source address length: 8
2019-02-19 17:19:55,851 - INFO #           Link type: wireless
2019-02-19 17:19:55,855 - INFO #           inet6 addr: fe80::7b7d:362c:c959:65a  scope: local  VAL
2019-02-19 17:19:55,857 - INFO #           inet6 group: ff02::2
2019-02-19 17:19:55,859 - INFO #           inet6 group: ff02::1
2019-02-19 17:19:55,862 - INFO #           inet6 group: ff02::1:ff59:65a
2019-02-19 17:19:55,865 - INFO #           inet6 group: ff02::1a
2019-02-19 17:19:55,865 - INFO #           
2019-02-19 17:19:55,868 - INFO #           Statistics for Layer 2
2019-02-19 17:19:55,872 - INFO #             RX packets 305  bytes 21320
2019-02-19 17:19:55,879 - INFO #             TX packets 218 (Multicast: 150)  bytes 10286
2019-02-19 17:19:55,885 - INFO #             TX succeeded 194 errors 0
2019-02-19 17:19:55,888 - INFO #           Statistics for IPv6
2019-02-19 17:19:55,890 - INFO #             RX packets 264  bytes 25312
2019-02-19 17:19:55,894 - INFO #             TX packets 218 (Multicast: 150)  bytes 14530
2019-02-19 17:19:55,895 - INFO #             TX succeeded 218 errors 0

On Zephyr

ieee802154 set_chan 26
ieee802154 set_pan_id abcd
ieee802154 set_short_addr 3

Observe the network configuration

uart:~$ net iface show

Interface 0x2000d9c0 (IEEE 802.15.4) [1]
========================================
Link addr : 0F:07:D5:E9:07:C9:57:2D
MTU       : 125
IPv6 unicast addresses (max 3):
        fe80::d07:d5e9:7c9:572d autoconf preferred infinite
        2001:db8::1 manual preferred infinite
IPv6 multicast addresses (max 4):
        ff02::1
        ff02::1:ffc9:572d
        ff02::1:ff00:1
IPv6 prefixes (max 2):
        <none>
IPv6 hop limit           : 64
IPv6 base reachable time : 30000
IPv6 reachable time      : 43867
IPv6 retransmit timer    : 0

So we've got the following addresses:

• Linux (long): fe80::186a:33b1:1ba0:1212
• Linux (short): fe80::a9cd:ff:fe00:1
• RIOT: fe80::7b7d:362c:c959:65a
• Zephyr: fe80::d07:d5e9:7c9:572d

Expected results

Everyone should be able to talk to each other.

Actual results

on RIOT

> ping6 fe80::186a:33b1:1ba0:1212 # Linux (long)
2019-02-19 17:58:25,924 - INFO # 12 bytes from fe80::186a:33b1:1ba0:1212: icmp_seq=0 ttl=64 time=25.288 ms
2019-02-19 17:58:26,907 - INFO # 12 bytes from fe80::186a:33b1:1ba0:1212: icmp_seq=1 ttl=64 time=7.609 ms
2019-02-19 17:58:27,911 - INFO # 12 bytes from fe80::186a:33b1:1ba0:1212: icmp_seq=2 ttl=64 time=9.195 ms
2019-02-19 17:58:27,912 - INFO # 
2019-02-19 17:58:27,915 - INFO # --- fe80::186a:33b1:1ba0:1212 PING statistics ---
2019-02-19 17:58:27,920 - INFO # 3 packets transmitted, 3 packets received, 0% packet loss
2019-02-19 17:58:27,931 - INFO # round-trip min/avg/max = 7.609/14.030/25.288 ms

> ping6 fe80::a9cd:ff:fe00:1:1 # Linux (short)
2019-02-19 17:58:47,425 - INFO # 
2019-02-19 17:58:47,430 - INFO # --- fe80::a9cd:ff:fe00:1 PING statistics ---
2019-02-19 17:58:47,433 - INFO # 3 packets transmitted, 0 packets received, 100% packet loss

> ping6 fe80::d07:d5e9:7c9:572d # Zephyr
2019-02-19 18:00:10,698 - INFO # 12 bytes from fe80::d07:d5e9:7c9:572d: icmp_seq=0 ttl=64 time=15.687 ms
2019-02-19 18:00:11,690 - INFO # 12 bytes from fe80::d07:d5e9:7c9:572d: icmp_seq=1 ttl=64 time=5.964 ms
2019-02-19 18:00:12,692 - INFO # 12 bytes from fe80::d07:d5e9:7c9:572d: icmp_seq=2 ttl=64 time=6.273 ms
2019-02-19 18:00:12,692 - INFO # 
2019-02-19 18:00:12,696 - INFO # --- fe80::d07:d5e9:7c9:572d PING statistics ---
2019-02-19 18:00:12,701 - INFO # 3 packets transmitted, 3 packets received, 0% packet loss
2019-02-19 18:00:12,711 - INFO # round-trip min/avg/max = 5.964/9.308/15.687 ms

on Zephyr

uart:~$ net ping fe80::7b7d:362c:c959:65a # RIOT
Sent a ping to fe80::7b7d:362c:c959:65a
Received echo reply from fe80::7b7d:362c:c959:65a to fe80::d07:d5e9:7c9:572d
uart:~$ net ping fe80::186a:33b1:1ba0:1212 # Linux (long)
Sent a ping to fe80::186a:33b1:1ba0:1212
Ping timeout
[01:11:04.003,692] <err> net_ieee802154_frame: Could not generate data frame 13 vs 21
uart:~$ net ping fe80::a9cd:ff:fe00:1 # Linux (short)
Sent a ping to fe80::a9cd:ff:fe00:1
Received echo reply from fe80::a9cd:ff:fe00:1 to fe80::d07:d5e9:7c9:572d

on Linux

$ ping -c2 -I lowpan0 fe80::7b7d:362c:c959:65a # RIOT
PING fe80::7b7d:362c:c959:65a(fe80::7b7d:362c:c959:65a) from fe80::a9cd:ff:fe00:1%lowpan0 lowpan0: 56 data bytes
^C
--- fe80::7b7d:362c:c959:65a ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1051ms

$ ping -c2 -I lowpan0 fe80::d07:d5e9:7c9:572d # Zephyr
PING fe80::d07:d5e9:7c9:572d(fe80::d07:d5e9:7c9:572d) from fe80::a9cd:ff:fe00:1%lowpan0 lowpan0: 56 data bytes
64 bytes from fe80::d07:d5e9:7c9:572d%lowpan0: icmp_seq=1 ttl=64 time=19.1 ms
64 bytes from fe80::d07:d5e9:7c9:572d%lowpan0: icmp_seq=2 ttl=64 time=10.0 ms

--- fe80::d07:d5e9:7c9:572d ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 10.092/14.625/19.158/4.533 ms

but wait - what if instead of an interface, we specify the source IP?

$ ping -c2 -I fe80::186a:33b1:1ba0:1212%lowpan0 fe80::7b7d:362c:c959:65a # RIOT using long source
PING fe80::7b7d:362c:c959:65a(fe80::7b7d:362c:c959:65a) from fe80::186a:33b1:1ba0:1212%lowpan0 lowpan0: 56 data bytes
64 bytes from fe80::7b7d:362c:c959:65a%lowpan0: icmp_seq=1 ttl=64 time=11.3 ms
64 bytes from fe80::7b7d:362c:c959:65a%lowpan0: icmp_seq=2 ttl=64 time=12.4 ms

--- fe80::7b7d:362c:c959:65a ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 11.393/11.906/12.420/0.524 ms


$ ping -c2 -I fe80::a9cd:ff:fe00:1%lowpan0 fe80::7b7d:362c:c959:65a # RIOT using short source
PING fe80::7b7d:362c:c959:65a(fe80::7b7d:362c:c959:65a) from fe80::a9cd:ff:fe00:1%lowpan0 lowpan0: 56 data bytes
^C
--- fe80::7b7d:362c:c959:65a ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1030ms

Interesting!

$ ping -c2 -I fe80::a9cd:ff:fe00:1%lowpan0 fe80::d07:d5e9:7c9:572d # Zephyr using short source
PING fe80::d07:d5e9:7c9:572d(fe80::d07:d5e9:7c9:572d) from fe80::a9cd:ff:fe00:1%lowpan0 lowpan0: 56 data bytes
64 bytes from fe80::d07:d5e9:7c9:572d%lowpan0: icmp_seq=1 ttl=64 time=19.3 ms
64 bytes from fe80::d07:d5e9:7c9:572d%lowpan0: icmp_seq=2 ttl=64 time=9.80 ms

--- fe80::d07:d5e9:7c9:572d ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 9.805/14.594/19.384/4.791 ms

$ ping -c2 -I fe80::186a:33b1:1ba0:1212%lowpan0 fe80::d07:d5e9:7c9:572d # Zephyr using long source
PING fe80::d07:d5e9:7c9:572d(fe80::d07:d5e9:7c9:572d) from fe80::186a:33b1:1ba0:1212%lowpan0 lowpan0: 56 data bytes
^C
--- fe80::d07:d5e9:7c9:572d ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1071ms

Now what to make out of this, I don't know. I find those results rather surprising, at least now they are documented somewhere.

I also prepared a second raspberry pi to check how Linux <-> Linux handles the 4 possible short / long source / destination combinations. Here all combinations do work.

It should be noted that when no short addresses are used, everyone is able to send and receive packets from everyone else.

Versions

RIOT: 2019.01 (master branch @ 5d481c2)
Linux: 4.19.20+ #1201 Tue Feb 12 21:55:56 GMT 2019 armv6l
Zephyr: v1.14.0 (master branch)

[PeterKietzmann]

@jia200x you have the equipped PI on your desk anyway. Mind to give it a try?

[jia200x]

@PeterKietzmann sure

[alexaring]

Meh, I guess I know why this happens :-(

08:14 + eintopf >> but then I can say normal ndisc with short address is broken either on riot or linux
08:15 + eintopf >> I am aware that I do it different what RIOT is doing :-/
08:15 + eintopf >> in short: RIOT 802.15.4 6lowpan handles short/extended as xor, where Linux handles it as or
08:17 + eintopf >> and the or strategy on Linux is "saving payload" (should be there exists more cases where we can save payload but it's not implemented yet")
08:18 + eintopf >> as it is it always use short when short is available but it depends on IPv6 header if extended may compress more for you - read the RFCs to know why
08:26 + eintopf >> Bergzand: or or xor - this is here the question and MAC is or

10:04 + eintopf >> Bergzand: after walking to the office: the addrlen setting in RIOT is wrong to have
10:04 + eintopf >> could be a per frame option but not per interface

So, I am either not sure if short/extended should be handled as or "or" xor.

@miri64 So we put extended AND short in address options fields of ndisc messages if short address is available. Also note that RA will generate two addresses for SLAAC if short is available. I think RIOT can't deal with that and it was already so as I added this feature :-X

In Linux exists a per interface type ndisc layer hook for doing additional handling. Look what we doing there: https://elixir.bootlin.com/linux/latest/source/net/6lowpan/ndisc.c

At least the extended addr is always available but RIOT seems to drop such ndisc messages when short is available. If RIOT will not drop and parse extended only then at least a connection would work again.

[roberthartung]

ping Any news on this?

[miri64]

I'll have some time again, I'll have a look into this soonish.

[alexaring]

have fun :-)

[miri64]

Sadly, no news (and no time so far) :( Can somebody try @alexaring's proposal?