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

Alexander Aring alex.aring at gmail.com
Sun Apr 24 22:05:30 CEST 2016


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

More information about the devel mailing list