Re: [riot-devel] RIOT+ULAs: no router entry

Re: [riot-devel] RIOT+ULAs: no router entry

[Alexander Aring]

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;
        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.

---

Also for processing NS the "::" seems to be different [1], "::" seems to
valid (ARO will be ignored than but we don't support it so it's default
ignored). :-)

- Alex

[0] https://tools.ietf.org/html/rfc6775#section-5.5.1
[1] https://tools.ietf.org/html/rfc6775#section-6.5

Re: [riot-devel] RIOT+ULAs: no router entry

[Alexander Aring]

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

Re: [riot-devel] RIOT+ULAs: no router entry

[smlng]

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@gmail.com>:
> 
> 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@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] RIOT+ULAs: no router entry

[Alexander Aring]

On Fri, Apr 29, 2016 at 04:58:04PM +0200, smlng wrote:
> 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?

Routers are indicated by the "forwarding" setting. radvd silent warns
about that if this isn't set for interfaces with RA advert is on, so far I
know you need to increase the debug level for that.

I simple set:

echo 1 > /proc/sys/net/ipv6/conf/all/forwarding

this will set forwarding for all interfaces.

Some code explaining:

See http://lxr.free-electrons.com/source/net/ipv6/ndisc.c#L838

this is at function when NS is received, the routeri flag will be set when
forwarding is enabled.

Maybe this solves all your current issues. :-)

> I'm running latest Raspbian with Kernel 'Linux raspberrypi 4.1.19+' and wpan-tools from github on the RasPi.
> 

I would better use bluetooth-next, if possible. With all recent patches
you could also try to use 6CO in radvd.

btw: the radvd wants to accept my patches for 6lowpan 6CO stuff, but
basic 6LoWPAN-ND (first short address support for NA/NS) will be added
and short-address handling will not work with RIOT, but that's another
issue...

- Alex

Re: [riot-devel] RIOT+ULAs: no router entry

[smlng]

Hi Alex, and all,

> Am 29.04.2016 um 17:25 schrieb Alexander Aring <alex.aring@gmail.com>:
> 
> Routers are indicated by the "forwarding" setting. radvd silent warns
> about that if this isn't set for interfaces with RA advert is on, so far I
> know you need to increase the debug level for that.
> 
> I simple set:
> 
> echo 1 > /proc/sys/net/ipv6/conf/all/forwarding
> 
> this will set forwarding for all interfaces.
> 
> Some code explaining:
> 
> See http://lxr.free-electrons.com/source/net/ipv6/ndisc.c#L838
> 
> this is at function when NS is received, the routeri flag will be set when
> forwarding is enabled.
> 
> Maybe this solves all your current issues. :-)

Yep, thanks - that did the trick. 

I wonder why it isn't sufficient to set 'echo 1 > /proc/sys/net/ipv6/conf/lowpan0/forwarding' on that specific lowpan interface? I tried it, but `radvd` still complains (debug level 5) that forwarding is 0. However, it works by enabling it for all IPv6 interfaces as you suggested.

> 
>> I'm running latest Raspbian with Kernel 'Linux raspberrypi 4.1.19+' and wpan-tools from github on the RasPi.
>> 
> 
> I would better use bluetooth-next, if possible. With all recent patches
> you could also try to use 6CO in radvd.

mhm, I'm using default Raspbian with RPI-Linux+DTS-overlay 'at86rf233' as it is cause a fast and easy setup - and until now, this was sufficient for my test cases ...

Best,
 Sebastian

[mail]: s@mlng.net
[code]: https://github.com/smlng