[riot-devel] RIOT+ULAs: no router entry
alex.aring at gmail.com
Fri Apr 22 14:28:17 CEST 2016
On Fri, Apr 22, 2016 at 01:13:29PM +0200, smlng wrote:
> Hi Alex, and all,
> my radvd.conf is the following:
> interface lowpan0
> AdvSendAdvert on;
> UnicastOnly on;
> AdvCurHopLimit 255;
> AdvSourceLLAddress on;
> MinRtrAdvInterval 3;
> MaxRtrAdvInterval 10;
With MaxRtrAdvInterval 10 then the:
will be 3 * 10 = 30 seconds. Don't know if this is anything related to
it. It should be send another RA messages in the interval of 3-10, so
far I know. In this interval the route (on RIOT side) should be updated,
I think in my setup I used a high value (9000) for this to make anything
working. :-) I can imagine this parameter will not fix this issue, so it
happens later only.
"Must be either zero or between MaxRtrAdvInterval and 9000 seconds."
Also sending periodic RA messages is some optional feature , but if I
remember correctly I used also a periodic transmit, because my RIOT node
never send another RS messages after booting and after lifetime ends it
didn't work anymore and that was the reason for high lifetime. :-)
So far my expierence. And newbie question: When it's needed to send RS
messages? Maybe it's , so far 6775 doesn't update it.
> AdvDefaultPreference low;
> prefix fd4b:c597:5df5:0::/64
> AdvOnLink off;
> AdvAutonomous on;
> AdvRouterAddr on;
> abro fe80::1ac0:ffee:1ac0:ffee
> AdvVersionLow 10;
> AdvVersionHigh 2;
> AdvValidLifeTime 2;
thanks, maybe I can reproduce it now.
btw: with recent kernel and linux-wpan/radvd -> 6lowpan branch you can
also use 6CO to add your prefix for stateful compression.
> btw. I use your/linux-wpan fork of radvd. Again: RIOT does receive the RA from radvd AND configures an IP with the provided prefix. Thus, the processing of RS+RA up this point seems to be correct, what's missing is the routers entry in RIOT. Further, RIOT does receive the COAP requests but it cannot send any reply, as it does not know the LLaddr for the destination (ULA) IP. As far as I remember my last digging into RIOTs NDP processing, RIOT does the following:
> 1. if DST_IP is link-local: extract LLaddr
> 2. else if neighbor cache entry exist, use it
> 3. if no ncache: query (default) router for LLaddr
> 4. if no router: abort
> I think I'm running into case 4, where no entry exists what so ever and thus no COAP reply is send.
> @Alex as you joined the discussion: I also have a question regarding the Linux side. I currently use Raspbian with shipped Linux-Kernel 4.1.19. I observed that Linux still does NS for link-local address via the nodes scoped multicast address, instead of using 6lo 'shortcut' by extracting LL/MAC-address from the link-local IP. Is this fixed in some recent version?
There are currently pending patches for introducing neigh_ops, which is
a callback strucuture for send/recv NS/NA. After this is mainline it
should be easily to change this behaviour, or? What do you think?
See  - function "lowpan_ndisc_send_ns".
Can you show me the part in rfc6775 which describe that behaviour?
Also I need to admit that I am not an expert in 6LoWPAN-ND. :-)
More information about the devel