gnrc_sixlowpan_nhc: fix forwarding case

[miri64]

Alternative to #5926 as proposed by @Yonezawa-T2. @smlng I was not able to reproduce your scenario, since my CoAP server always connected to the border router automatically. Can you tell me how to blacklist that? I'd like to have this fixed also.

[smlng]

@miri64 I use a patched version of RIOT+RPL (see here), where I blacklist a certain node that is not allowed as parent, i.e., the RPL root in my scenario. You can specifiy the MAC address of that node in the Makefile by a macro.

So the first hop node is an unpatched RIOT+RPL and the second hope nodes uses the described mod with the RPL root (or border router) as denied parent.

[miri64]

Okay, will try that. Tomorrow ;-)

[miri64]

Okay, I tried it now but with a different hack directly on the link layer:

diff --git a/sys/net/gnrc/link_layer/netdev2/gnrc_netdev2_ieee802154.c b/sys/net/gnrc/link_layer/netdev2/gnrc_netdev2_ieee802154.c
index 4903662..ad7eb42 100644
--- a/sys/net/gnrc/link_layer/netdev2/gnrc_netdev2_ieee802154.c
+++ b/sys/net/gnrc/link_layer/netdev2/gnrc_netdev2_ieee802154.c
@@ -24,6 +24,10 @@
 #define ENABLE_DEBUG    (0)
 #include "debug.h"

+#ifdef GNRC_NETDEV2_IEEE802154_IGNORE
+static uint8_t _ignore[][IEEE802154_LONG_ADDRESS_LEN] = GNRC_NETDEV2_IEEE802154_IGNORE;
+#endif
+
 static gnrc_pktsnip_t *_recv(gnrc_netdev2_t *gnrc_netdev2);
 static int _send(gnrc_netdev2_t *gnrc_netdev2, gnrc_pktsnip_t *pkt);

@@ -50,6 +54,15 @@ static gnrc_pktsnip_t *_make_netif_hdr(uint8_t *mhr)
         DEBUG("_make_netif_hdr: unable to get addresses\n");
         return NULL;
     }
+#ifdef GNRC_NETDEV2_IEEE802154_IGNORE
+    for (unsigned i = 0; i < (sizeof(_ignore) / IEEE802154_LONG_ADDRESS_LEN);
+         i++) {
+        if (memcmp(_ignore[i], src, src_len) == 0) {
+            DEBUG("_make_netif_hdr: source address ignored\n");
+            return NULL;
+        }
+    }
+#endif
     /* allocate space for header */
     snip = gnrc_netif_hdr_build(src, (size_t)src_len, dst, (size_t)dst_len);
     if (snip == NULL) {

I can't however confirm the behavior @smlng have shown in #5926 :(. My dumps come out as expected. If I can get a second confirmation (@aabadie, @kYc0o?) I would prefer to merge this ASAP and figure out later what @smlng's specific problem is.

[miri64]

(I used the examples/microcoap_server as a CoAP server btw)

[kYc0o]

@aabadie I tried the IoT-Lab CoAP tutorial with this PR but it didn't work... Before stating that this PR doesn't solve the problem, could you try it too?

[miri64]

Can you describe this scenario (or give me a link) so I can try myself instead of poking in the dark ;-)

[kYc0o]

You can try this tutorial but using the current master PR as RIOT source. You should be able to ping and access CoAP resources from anywhere using IPv6 addresses.

EDIT: I meant to try the tutorial with this PR merged into master.

[miri64]

You should be able to ping and access CoAP resources from anywhere using IPv6 addresses.

I thought this is not possible oO

[kYc0o]

It IS possible ;-)

[miri64]

Then why do we need this fix?!!?

[miri64]

Also

@aabadie I tried the IoT-Lab CoAP tutorial with this PR but it didn't work... Before stating that this PR doesn't solve the problem, could you try it too?

I am very confused now.

[kYc0o]

Well... it WAS possible, this PR it's aiming to fix it isn't it?

[miri64]

Also: I noticed that since microcoap_server was downgraded to a host the RPL PIO (because it isn't part of that DODAG anymore) isn't distributed to it and there seems to be a problem with multihop ND PIO distribution. Can you confirm first, that the issue is really due to UDP packets not being forwarded properly and not due to the microcoap_server not having a prefix configured?

[miri64]

(BTW Point 7 of the tutorial can now be made with make term ;-))

[kYc0o]

The tutorial works with a specific version of RIOT which is quite old, before the introduction of a PR which break this functionality (I'll try to point out which one), so with this fix it's supposed to work again with the current master.

Can you confirm first, that the issue is really due to UDP packets not being forwarded properly and not due to the microcoap_server not having a prefix configured?

Pings succeed while CoAP requests don't. As for the prefix I checked and it has one.

[miri64]

Okay, will check tomorrow as to why that is.

[kYc0o]

Edited comment.

[aabadie]

@miri64 @kYc0o tested this on IoT-LAB, following the BR tutorial => works

If you have ipv6 and can reach the microcoap server running on one of the nodes of my experiment (will end in half an hour) :
coap://[2001:660:3207:409:3432:4833:46d4:9c16]:5683/riot/board

[miri64]

Confirmed

[miri64]

@aabadie do you give an ACK then? :D

[aabadie]

ACK

[miri64]

Murdock is also happy :-)

[aabadie]

So go !

[miri64]

Backport provided in #6095