* Re: [riot-devel] RIOT+ULAs: no router entry [not found] ` <20160422122816.GA6364@omega> @ 2016-04-24 20:05 ` Alexander Aring 2016-04-24 20:31 ` Alexander Aring 0 siblings, 1 reply; 5+ messages in thread From: Alexander Aring @ 2016-04-24 20:05 UTC (permalink / raw) To: RIOT OS kernel developers; +Cc: linux-wpan 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 ^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [riot-devel] RIOT+ULAs: no router entry 2016-04-24 20:05 ` [riot-devel] RIOT+ULAs: no router entry Alexander Aring @ 2016-04-24 20:31 ` Alexander Aring 2016-04-29 14:58 ` smlng 0 siblings, 1 reply; 5+ messages in thread From: Alexander Aring @ 2016-04-24 20:31 UTC (permalink / raw) To: RIOT OS kernel developers; +Cc: linux-wpan 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [riot-devel] RIOT+ULAs: no router entry 2016-04-24 20:31 ` Alexander Aring @ 2016-04-29 14:58 ` smlng 2016-04-29 15:25 ` Alexander Aring 0 siblings, 1 reply; 5+ messages in thread From: smlng @ 2016-04-29 14:58 UTC (permalink / raw) To: linux-wpan; +Cc: RIOT OS kernel developers 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [riot-devel] RIOT+ULAs: no router entry 2016-04-29 14:58 ` smlng @ 2016-04-29 15:25 ` Alexander Aring 2016-04-29 17:06 ` smlng 0 siblings, 1 reply; 5+ messages in thread From: Alexander Aring @ 2016-04-29 15:25 UTC (permalink / raw) To: RIOT OS kernel developers; +Cc: linux-wpan 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [riot-devel] RIOT+ULAs: no router entry 2016-04-29 15:25 ` Alexander Aring @ 2016-04-29 17:06 ` smlng 0 siblings, 0 replies; 5+ messages in thread From: smlng @ 2016-04-29 17:06 UTC (permalink / raw) To: RIOT OS kernel developers; +Cc: linux-wpan 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2016-04-29 17:12 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <B354489C-54BF-4CAF-8B41-04A946D83478@mlng.net>
[not found] ` <20160422102833.GA5671@omega>
[not found] ` <7BCB9BD8-C255-458C-83F6-0F7FE69F5C7F@mlng.net>
[not found] ` <20160422122816.GA6364@omega>
2016-04-24 20:05 ` [riot-devel] RIOT+ULAs: no router entry Alexander Aring
2016-04-24 20:31 ` Alexander Aring
2016-04-29 14:58 ` smlng
2016-04-29 15:25 ` Alexander Aring
2016-04-29 17:06 ` smlng
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.