6LowPAN and Linux radvd issue

Hi,

this may be more related to the Linux side of the system, but I’m not completely sure so I figured I’d ask.

I’m trying to get a 6LowPAN network running between a RIOT device and an embedded Linux border router.

I’m using a SAMR30 for the RIOT device using the gnrc_networking example and an embedded Linux device (not RPi) with an RF212 radio.

I have been able to bring up a lowpan network and can ping from both devices using the link local addresses.

I have been referencing a Linux Journal article for all of this: https://jan.newmarch.name/IoT/LinuxJournal/Routing/

I configure radvd on the Linux device to provide a global address to the RIOT device which is does, config below. The boarder router global address is set to fd28::1. The RIOT device gets a global address of fd28::ec0a:363b:7506:d64d.

I can ping fd28::1 from the RIOT device, but I cannot ping the global address assigned to the RIOT device from the Linux board.

This could be me not understanding ipv6, but I thought that it sohould be a routable address an directly reachable from the border router’s interface.

Any ideas what I’m missing?

Thanks, Matt

radvd.conf: interface lowpan0 { AdvSendAdvert on; AdvCurHopLimit 255; AdvSourceLLAddress on;

prefix fd28::/64
{
	#AdvOnLink off;
	AdvOnLink on;
	AdvAutonomous on;
	AdvRouterAddr on;
};

abro fe80::1
{
	AdvVersionLow 10;
	AdvVersionHigh 2;
	AdvValidLifeTime 2;
};

};

Linux box:

ifconfig

lowpan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1280 metric 1 inet6 fe80::24db:56ee:8137:dc92 prefixlen 64 scopeid 0x20 inet6 fd28::1 prefixlen 64 scopeid 0x0 inet6 fd28::24db:56ee:8137:dc92 prefixlen 64 scopeid 0x0 unspec 26-DB-56-EE-81-37-DC-92-00-00-00-00-00-00-00-00 txqueuelen 1000 (UNSPEC) RX packets 86 bytes 6422 (6.2 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 143 bytes 13280 (12.9 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

wpan0: flags=195<UP,BROADCAST,RUNNING,NOARP> mtu 123 metric 1 unspec 26-DB-56-EE-81-37-DC-92-00-00-00-00-00-00-00-00 txqueuelen 300 (UNSPEC) RX packets 86 bytes 3885 (3.7 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 151 bytes 12790 (12.4 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

ping6 -I lowpan0 fd28::ec0a:363b:7506:d64d

PING fd28::ec0a:363b:7506:d64d (fd28::ec0a:363b:7506:d64d): 56 data bytes // nothing …

ping6 -I lowpan0 fe80::ec0a:363b:7506:d64d

PING fe80::ec0a:363b:7506:d64d (fe80::ec0a:363b:7506:d64d): 56 data bytes 64 bytes from fe80::ec0a:363b:7506:d64d: seq=0 ttl=255 time=13.733 ms 64 bytes from fe80::ec0a:363b:7506:d64d: seq=1 ttl=255 time=12.483 ms 64 bytes from fe80::ec0a:363b:7506:d64d: seq=2 ttl=255 time=14.133 ms

RIOT device:

ifconfig Iface 6 HWaddr: 56:4D Channel: 5 Page: 2 NID: 0x23 PHY: O-QPSK

      Long HWaddr: EE:0A:36:3B:75:06:D6:4D 
       TX-Power: 0dBm  State: IDLE  max. Retrans.: 3  CSMA Retries: 4 
      AUTOACK  ACK_REQ  CSMA  L2-PDU:102  MTU:1280  HL:255  RTR  
      RTR_ADV  6LO  IPHC  
      Source address length: 8
      Link type: wireless
      inet6 addr: fe80::ec0a:363b:7506:d64d  scope: link  VAL
      inet6 addr: fd28::ec0a:363b:7506:d64d  scope: global  TNT[3]
      inet6 group: ff02::2
      inet6 group: ff02::1
      inet6 group: ff02::1:ff06:d64d
      inet6 group: ff02::1a
      
      Statistics for Layer 2
        RX packets 67  bytes 6735
        TX packets 37 (Multicast: 9)  bytes 2407
        TX succeeded 37 errors 0
      Statistics for IPv6
        RX packets 67  bytes 6296
        TX packets 37 (Multicast: 9)  bytes 2874
        TX succeeded 37 errors 0

ping fd28::1 12 bytes from fd28::1: icmp_seq=0 ttl=255 rssi=-46 dBm time=10.010 ms 12 bytes from fd28::1: icmp_seq=1 ttl=255 rssi=-46 dBm time=8.856 ms 12 bytes from fd28::1: icmp_seq=2 ttl=255 rssi=-47 dBm time=10.478 ms

— fd28::1 PING statistics — 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 8.856/9.781/10.478 ms

That looks like an ULA and not GUA. Correct me if I am wrong.

Using a private address range for the sensor network is perfectly fine.

Do you have a route t the network configured on your Linux box? You can check with ip -6 route.

Does your interface on RIOT stay in the TNT[3] state? It will only be reachable through that address once it changes to VALid, so if it’s stuck there the issue would be that.

The question then is why it is stuck there doing duplicate address detection. There was a bug in RIOT there in the past, but unless you are using a really old version that should be fixed.

I was playing around with things and made some changes to the radvd config - now I’m using a hard coded LL and a new valid /64 prefix and IP address: prefix fde1:cb6f:732a:8706::/64 abro fde1:cb6f:732a:8706:0:0:0:1

I do see the RIOT device stuck at TNT 3 which is interesting. I’m using the 2022.04 tag and simply built the gnrc_networking example unmodified. I just tried the master branch but no change either. I looked at the routing table on both sides as well as the neighbor data.

Thanks, Matt.

ip -6 route

::1 dev lo proto kernel metric 256 pref medium fde1:cb6f:732a:8706::1 dev lowpan0 proto kernel metric 256 pref medium fe80::/64 dev eth0 proto kernel metric 256 pref medium fe80::/64 dev lowpan0 proto kernel metric 256 pref medium

ip -6 neigh show

fe80::ec0a:363b:7506:d64d dev lowpan0 lladdr ee:0a:36:3b:75:06:d6:4d router STALE fe80::24db:56ee:8137:dc92 dev lowpan0 lladdr 26:db:56:ee:81:37:dc:92 router STALE fde1:cb6f:732a:8706:ec0a:363b:7506:d64d dev lowpan0 lladdr ee:0a:36:3b:75:06:d6:4d router STALE

ping6 -I lowpan0 fde1:cb6f:732a:8706:ec0a:363b:7506:d64d

PING fde1:cb6f:732a:8706:ec0a:363b:7506:d64d (fde1:cb6f:732a:8706:ec0a:363b:7506:d64d): 56 data bytes ping6: sendto: Network is unreachable

ping6 -I lowpan0 fe80::ec0a:363b:7506:d64d

PING fe80::ec0a:363b:7506:d64d (fe80::ec0a:363b:7506:d64d): 56 data bytes 64 bytes from fe80::ec0a:363b:7506:d64d: seq=0 ttl=255 time=17.437 ms 64 bytes from fe80::ec0a:363b:7506:d64d: seq=1 ttl=255 time=11.910 ms 64 bytes from fe80::ec0a:363b:7506:d64d: seq=2 ttl=255 time=10.779 ms ^C — fe80::ec0a:363b:7506:d64d ping statistics — 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 10.779/13.375/17.437 ms

ip -6 neigh show

fe80::ec0a:363b:7506:d64d dev lowpan0 lladdr ee:0a:36:3b:75:06:d6:4d router REACHABLE fe80::24db:56ee:8137:dc92 dev lowpan0 lladdr 26:db:56:ee:81:37:dc:92 router STALE fde1:cb6f:732a:8706:ec0a:363b:7506:d64d dev lowpan0 lladdr ee:0a:36:3b:75:06:d6:4d router REACHABLE fe80::36af:b3ff:fe9c:5e4a dev eth0 lladdr 34:af:b3:9c:5e:4a STALE

ping6 -I lowpan0 fde1:cb6f:732a:8706:ec0a:363b:7506:d64d

PING fde1:cb6f:732a:8706:ec0a:363b:7506:d64d (fde1:cb6f:732a:8706:ec0a:363b:7506:d64d): 56 data bytes ping6: sendto: Network is unreachable

nib neigh fe80::24db:56ee:8137:dc92 dev #6 lladdr 26:DB:56:EE:81:37:DC:92 router REACHABLE GC nib prefix fde1:cb6f:732a:8706::/64 dev #6 expires 86398 sec deprecates 14398 sec nib route fde1:cb6f:732a:8706::/64 dev #6 default via fe80::24db:56ee:8137:dc92 dev #6 nib abr fde1:cb6f:732a:8706::1 v0 expires 71582min

Ok this is really strange.

I changed my sysctl to disable forwarding: net.ipv6.conf.all.forwarding = 0

I still cannot ping the RIOT node but it does not say “network unreachable” any more. If I run the udp server on the RIOT node I can make a connection with the global address. But, its still showing TNT for the global SLAAC generated address on the node. That is the only ipv6 specific setting that are set (i.e sysctl -p).

This might be outdated, but I think RIOT needs a special flag to actually use a SLAAC address on 6lowpan interfaces. Can you try compiling gnrc_networking with CFLAGS=-DCONFIG_GNRC_IPV6_NIB_SLAAC=1?

Well that seems to be the culprit. I can now ping both sides and work with UDP connections.

Thanks for the help!

1 Like