Hi Alex,
hi all,
over the last days I did some more extensive tests and enabled/added some debug output in RIOT, and I got close to the root cause of the problem.
TL;DR:
- Linux does not set the router flag in its NAs
- but it should when `radvd` is running (or `radvd` should enable it).
- RIOT behaves correctly, according to RFC-4861 7.2.4.
----
Now the slightly longer version; I quickly recap my setup:
- a RasPi with OpenLabs transceiver, and `radvd` (linux-wpan version from github)
- Atmel samr21-xpro running RIOT with `gnrc_networking` example (2016.04-branch)
- `radvd` announces a ULA-prefix (though ULA doesn't matter, could global as well)
I observed the following behavior:
- RIOT send RS on boot, `radvd` on RasPi replies with RA (incl. PIO, ABRO, SLLAO)
- RIOT parse RA, generates IP from prefix, adds NCE for router with router flag set
- RIOT send NS for RasPi/routers link-local address -> RasPi replies with NA
- RIOT parses NA, but router flag not set -> unset router flag in NCE of router
- hence no more router in cache -> no ping or data transfer via non-link-local (e.g. ULA) IPs
so my question @alex and @linux-wpan: can I manually set/enable the routers flag for NAs in Linux Kernel? Or somehow _convince_ `radvd` to do so on startup?
I'm running latest Raspbian with Kernel 'Linux raspberrypi 4.1.19+' and wpan-tools from github on the RasPi.
Best,
Sebastian
> Am 24.04.2016 um 22:31 schrieb Alexander Aring <alex.aring@xxxxxxxxx>:
>
> Hi,
>
> On Sun, Apr 24, 2016 at 10:05:28PM +0200, Alexander Aring wrote:
>> Hi,
>>
>> On Fri, Apr 22, 2016 at 02:28:16PM +0200, Alexander Aring wrote:
>>> On Fri, Apr 22, 2016 at 01:13:29PM +0200, smlng wrote:
>> ...
>>>>
>>>> @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 [3] - function "lowpan_ndisc_send_ns".
>>>
>>
>> I think, I know what you mean. There is some NS with src as unspecified
>> addr "::" and dest is some "multicast node scope".
>>
>> RFC 6775 says [0]:
>>
>> An unspecified source address MUST NOT be used in NS messages.
>>
>> Additional to the pending patches I added:
>>
>> diff --git a/net/6lowpan/ndisc.c b/net/6lowpan/ndisc.c
>> index d088295..c6207cd 100644
>> --- a/net/6lowpan/ndisc.c
>> +++ b/net/6lowpan/ndisc.c
>> @@ -386,8 +386,11 @@ static void lowpan_ndisc_send_ns(struct net_device *dev,
>> saddr = &addr_buf;
>> }
>>
>> + /* RFC6775:
>> + * An unspecified source address MUST NOT be used in NS messages.
>> + */
>> if (ipv6_addr_any(saddr))
>> - inc_opt = false;
>> + return;
>
> Question would here also, if we really wants to drop it or use ?link-local?
> saddr then.
>
>> if (inc_opt) {
>> optlen += ndisc_opt_addr_space(dev, dev->addr_len);
>> optlen += lowpan_ndisc_802154_short_addr_space(dev);
>>
>>
>> This will not sending NS with "::" addresses as source address.
>>
>> However, it's a little bit ugly we should prevent to calling this
>> callback when source address is "::".
>>
>> This patch should be fine at first but can maybe optimized in future.
>>
>
> I think what you ask is the complete ARO stuff support and I can't
> follow the:
>
> "by extracting LL/MAC-address from the link-local IP." in case of
> destination address and sending NS. What I found is the "Sending NS"
> section of rfc6775 [0], which doesn't say anything about different
> destination address.
>
> Also I found a bootstrapping example in case of 6LN -> 6LR, [1]. But they
> meant there the GP64 and link-local is defined as LL64.
>
> ...
>
> I think I need to look deeper into that to say something related to
> 6LoWPAN-ND. :-)
>
> - Alex
>
> [0] https://tools.ietf.org/html/rfc6775#section-5.5.1
> [1] https://tools.ietf.org/html/rfc6775#section-10.2.1
> _______________________________________________
> devel mailing list
> devel@xxxxxxxxxxx
> https://lists.riot-os.org/mailman/listinfo/devel
--
To unsubscribe from this list: send the line "unsubscribe linux-wpan" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
