| Message ID | 20160424200528.GA27492@omega (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
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 -- To unsubscribe from this list: send the line "unsubscribe linux-wpan" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-wpan" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-wpan" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-wpan" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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);