gnrc_ipv6_nib: use generated EUI-64 for ARO build and check by miri64 · Pull Request #10817 · RIOT-OS/RIOT

miri64 · 2019-01-18T14:58:43Z

Contribution description

This fixes #10723 by providing a new getter for the (unconverted) EUI-64 in the interface layer. This getter then is used instead of the link-layer address to set the EUI-64 in the ARO and also check it.

Testing procedure

Flash two 6Lo-capable boards with gnrc_border_router and gnrc_networking. The gnrc_networking should get a global address which will be marked as valid. Not just IEEE 802.15.4-capable boards should be able to do this now, but also BLE-based boards and more exotic candidates like cc110x, nrfmin, or esp-now.

Issues/PRs references

Closes #10723.

maribu

Found one minor nit and a potential bug

sys/net/gnrc/netif/gnrc_netif_device_type.c

gschorcht · 2019-01-18T16:21:19Z

Are PR #10499 and the extension of the list by NETDEV_TYPE_ESP_NOW here

RIOT/sys/net/gnrc/netif/gnrc_netif_device_type.c

Line 40 in 057f8cc

case NETDEV_TYPE_NRFMIN:

necessary that it can be tested with ESP-NOW?

miri64 · 2019-01-18T16:31:02Z

Are PR #10499 and the extension of the list by NETDEV_TYPE_ESP_NOW here

RIOT/sys/net/gnrc/netif/gnrc_netif_device_type.c

Line 40 in 057f8cc

case NETDEV_TYPE_NRFMIN:
necessary that it can be tested with ESP-NOW?

With this PR I believe the distinction shouldn't be necessary anymore (but it is still would make sense).

maribu · 2019-01-18T16:36:37Z

I think @gschorcht is currently reviewing, but when he is done feel free to rebase to address the alignment issue

gschorcht · 2019-01-18T16:52:45Z

I will do it tomorrow.

miri64 · 2019-01-18T16:55:58Z

Ok, then I rebase now.

miri64 · 2019-01-18T16:56:41Z

Done

gschorcht · 2019-01-19T09:54:16Z

👍 Works w/o PR #10499 with a border router with Ethernet connected to LAN and ESP-NOW on wireless side. Ethernet interface gets the global routing prefix from the router in LAN, ESP-NOW interface disseminates the 2001:db8::/64 prefix. ESP-NOW nodes get a valid 2001:db8::/64 address. ESP-NOW nodes can ping using the their global unicast addresses. If a node in the LAN has a configurerd route to 2001:db8::/64 via the border node, it can ping ESP-NOW nodes and vise versa.

The only one special configuration the border router required was GNRC_IPV6_NIB_CONF_SLAAC=1. Otherwise, neither link local nor global unicast addresses become valid. Is that the intended behaviour for an Ethernet interface as part of a 6LBR?

ESP-NOW nodes worked out of the box with examples/gnrc_networking configuration.

miri64 · 2019-01-19T09:56:56Z

Nope

miri64 · 2019-01-19T09:57:09Z

(on)

The only one special configuration the border router required was GNRC_IPV6_NIB_CONF_SLAAC=1. Otherwise, neither link local nor global unicast addresses become valid. Is that the intended behaviour for an Ethernet interface as part of a 6LBR?

gschorcht · 2019-01-19T10:20:15Z

Border router was compiled with following gnrc modules:

#define MODULE_GNRC 1
#define MODULE_GNRC_ICMPV6 1
#define MODULE_GNRC_ICMPV6_ECHO 1
#define MODULE_GNRC_IPV6 1
#define MODULE_GNRC_IPV6_HDR 1
#define MODULE_GNRC_IPV6_NIB 1
#define MODULE_GNRC_IPV6_NIB_6LBR 1
#define MODULE_GNRC_IPV6_NIB_6LN 1
#define MODULE_GNRC_IPV6_NIB_6LR 1
#define MODULE_GNRC_IPV6_NIB_ROUTER 1
#define MODULE_GNRC_IPV6_ROUTER 1
#define MODULE_GNRC_IPV6_ROUTER_DEFAULT 1
#define MODULE_GNRC_NDP 1
#define MODULE_GNRC_NETAPI 1
#define MODULE_GNRC_NETDEV_DEFAULT 1
#define MODULE_GNRC_NETIF 1
#define MODULE_GNRC_NETIF_ETHERNET 1
#define MODULE_GNRC_NETIF_HDR 1
#define MODULE_GNRC_NETREG 1
#define MODULE_GNRC_PKT 1
#define MODULE_GNRC_PKTBUF 1
#define MODULE_GNRC_PKTBUF_CMD 1
#define MODULE_GNRC_PKTBUF_STATIC 1
#define MODULE_GNRC_SIXLOWPAN 1
#define MODULE_GNRC_SIXLOWPAN_BORDER_ROUTER_DEFAULT 1
#define MODULE_GNRC_SIXLOWPAN_CTX 1
#define MODULE_GNRC_SIXLOWPAN_FRAG 1
#define MODULE_GNRC_SIXLOWPAN_IPHC 1
#define MODULE_GNRC_SIXLOWPAN_IPHC_NHC 1
#define MODULE_GNRC_SIXLOWPAN_ND 1
#define MODULE_GNRC_SIXLOWPAN_ROUTER 1
#define MODULE_GNRC_SIXLOWPAN_ROUTER_DEFAULT 1

miri64 · 2019-01-19T10:20:23Z

Thanks @gschorcht. I was planning to investigate, why the addresses never became valid on that interface. That explains it. I fixed it in #10824

gschorcht

ACK from my side

gschorcht · 2019-01-19T10:31:31Z

Should we have tests for all candidates?

miri64 · 2019-01-19T10:47:18Z

Should we have tests for all candidates?

We should at least test for cc110x and one IEEE 802.15.4 device, I think.

maribu · 2019-01-19T11:36:28Z

Ok, using the steps described in #10524 (comment) I was able to get ping both MSB-A2 hosts from the Linux host - the other way round did not work for me (but that was expected).

miri64 · 2019-01-19T11:39:54Z

(but that was expected).

Why?

miri64 · 2019-01-19T11:42:00Z

BTW for testing this PR myself I used the following patch for the gnrc_networking-based node with msba2:

diff --git a/drivers/cc110x/cc110x.c b/drivers/cc110x/cc110x.c
index 8230f9487..80c134115 100644
--- a/drivers/cc110x/cc110x.c
+++ b/drivers/cc110x/cc110x.c
@@ -81,8 +81,7 @@ int cc110x_setup(cc110x_t *dev, const cc110x_params_t *params)
     cc110x_set_channel(dev, CC110X_DEFAULT_CHANNEL);
 
     /* set default node id */
-    uint8_t addr;
-    luid_get(&addr, 1);
+    uint8_t addr = 45;
     cc110x_set_address(dev, addr);
 
     LOG_INFO("cc110x: initialized with address=%u and channel=%i\n",

This way everything bootstraps right from the start.

maribu · 2019-01-19T12:24:16Z

(but that was expected).

Why?

Oh, sorry I got confused with the PRs. I though this was a cleanup PR and thus assumed everything not working before cannot be expected to work afterwards.

Let me point out that I'm using an uncommon Linux distro. So the issue might be on the PC side as well.

sys/include/net/gnrc/netif/internal.h

cgundogan

The code is sensible, I have a minor nit below. It is not that important to address it within this PR, though, since you did not modify that function but rather moved. I cannot test right now with an 6lbr.

cgundogan · 2019-01-25T17:30:57Z

sys/net/gnrc/netif/gnrc_netif_device_type.c

+{
+    const unsigned offset = sizeof(eui64_t) - addr_len;
+
+    memset(eui64->uint8, 0, sizeof(eui64->uint8));


why did you not use an assignment statement here?

eui64->uint8[0] = 0x00;

okay, further down I did see that you basically moved this function up without any modifications.

because eui64->uint8 is an array, so

memset(eui64->uint8, 0, sizeof(eui64->uint8)); /* sets all elements of the array to 0 */

is not the same

as

eui64->uint8[0] = 0x00; /* sets the first element of the array to 0 */

;-P

mhm, true (: never mind then

miri64 · 2019-01-25T18:03:05Z

@aabadie @emmanuelsearch is this (bug fixing) PR too involved for a hotfix for the release or can it still go in? The issue it fixes won't show up in the release spec testings (however the bug fix might cause errors there when merged after improper testing ;-))

cgundogan

Also tested with a samr and iotlab using a border router and normal 6lo router. I get a valid IPv6 address! ACK!

cgundogan · 2019-01-29T20:42:04Z

ah, and please squash

miri64 · 2019-01-29T20:53:19Z

Squashed

miri64 · 2019-01-29T22:12:07Z

@aabadie @emmanuelsearch shall I backport?

aabadie · 2019-01-30T11:23:37Z

shall I backport?

It's a bug, so yes please!

miri64 · 2019-01-30T12:40:39Z

Backport provided in #10906

aabadie

Still no change, re-ACK.

miri64 added Type: bug The issue reports a bug / The PR fixes a bug (including spelling errors) Area: network Area: Networking CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR labels Jan 18, 2019

miri64 added this to the Release 2019.01 milestone Jan 18, 2019

miri64 requested review from cgundogan, gschorcht, haukepetersen and maribu January 18, 2019 14:58

miri64 mentioned this pull request Jan 18, 2019

gnrc_ipv6_nib: 6Lo-ND EUI-64 checks not portable #10723

Closed

miri64 changed the title ~~Gnrc netif/enh/i10723~~ gnrc_ipv6_nib: use generated EUI-64 for ARO build and check Jan 18, 2019

miri64 mentioned this pull request Jan 18, 2019

l2util: initial import of a general IPv6 over X helper module #10589

Merged

maribu reviewed Jan 18, 2019

View reviewed changes

sys/net/gnrc/netif/gnrc_netif_device_type.c Show resolved Hide resolved

sys/net/gnrc/netif/gnrc_netif_device_type.c Show resolved Hide resolved

miri64 mentioned this pull request Jan 18, 2019

eui48: fix type alignment #10820

Merged

miri64 force-pushed the gnrc_netif/enh/i10723 branch from f613022 to e6e6a4e Compare January 18, 2019 16:56

miri64 mentioned this pull request Jan 19, 2019

gnrc_ipv6_nib: activate SLAAC on border router #10824

Merged

gschorcht reviewed Jan 19, 2019

View reviewed changes

gschorcht mentioned this pull request Jan 24, 2019

gnrc_netif: introduce distinction if an interface supports 6Lo or if it performs ND according to RFC 6775 #10499

Merged

5 tasks

cgundogan reviewed Jan 25, 2019

View reviewed changes

sys/include/net/gnrc/netif/internal.h Outdated Show resolved Hide resolved

cgundogan reviewed Jan 25, 2019

View reviewed changes

miri64 added the Community: Hack'n'ACK candidate This PR is a candidate for review and discussion during one of RIOT's monthly Hack'n'ACK parties label Jan 29, 2019

cgundogan approved these changes Jan 29, 2019

View reviewed changes

miri64 added 6 commits January 29, 2019 21:52

eui48: introduce eui48_to_eui64() function

963b405

eui48: wrap eui48_to_ipv6_iid() around eui48_to_eui64()

9468342

gnrc_netif: rename _create_iid_from_short() to emphesize EUI-64

a2b2f96

gnrc_netif: introduce L2 address to EUI-64 conversion

16e7fc8

gnrc_netif: wrap _ipv6_iid_from_addr() around _eui64_from_addr()

0fa8419

gnrc_ipv6_nib: use gnrc_netif_get_eui64() for ARO build and check

d680aea

miri64 force-pushed the gnrc_netif/enh/i10723 branch from 3258003 to d680aea Compare January 29, 2019 20:53

cgundogan merged commit b3843da into RIOT-OS:master Jan 29, 2019

miri64 deleted the gnrc_netif/enh/i10723 branch January 29, 2019 22:11

miri64 mentioned this pull request Jan 30, 2019

gnrc_ipv6_nib: use generated EUI-64 for ARO build and check [backport 2019.01] #10906

Merged

aabadie reviewed Jan 30, 2019

View reviewed changes

gschorcht mentioned this pull request Mar 5, 2020

sys/net/gnrc: Flag esp_now as 6LN #13561

Merged

gschorcht mentioned this pull request Aug 6, 2020

examples/gnrc_border_router: esp_wifi crashes on disconnect #14679

Open

Conversation

miri64 commented Jan 18, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Contribution description

Testing procedure

Issues/PRs references

Uh oh!

maribu left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

gschorcht commented Jan 18, 2019

Uh oh!

miri64 commented Jan 18, 2019

Uh oh!

maribu commented Jan 18, 2019

Uh oh!

gschorcht commented Jan 18, 2019

Uh oh!

miri64 commented Jan 18, 2019

Uh oh!

miri64 commented Jan 18, 2019

Uh oh!

gschorcht commented Jan 19, 2019

Uh oh!

miri64 commented Jan 19, 2019

Uh oh!

miri64 commented Jan 19, 2019

Uh oh!

gschorcht commented Jan 19, 2019

Uh oh!

miri64 commented Jan 19, 2019

Uh oh!

gschorcht left a comment

Choose a reason for hiding this comment

Uh oh!

gschorcht commented Jan 19, 2019

Uh oh!

miri64 commented Jan 19, 2019

Uh oh!

maribu commented Jan 19, 2019

Uh oh!

miri64 commented Jan 19, 2019

Uh oh!

miri64 commented Jan 19, 2019

Uh oh!

maribu commented Jan 19, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

cgundogan left a comment

Choose a reason for hiding this comment

Uh oh!

cgundogan Jan 25, 2019

Choose a reason for hiding this comment

Uh oh!

cgundogan Jan 25, 2019

Choose a reason for hiding this comment

Uh oh!

miri64 Jan 25, 2019

Choose a reason for hiding this comment

Uh oh!

cgundogan Jan 25, 2019

Choose a reason for hiding this comment

Uh oh!

miri64 commented Jan 25, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

cgundogan left a comment

Choose a reason for hiding this comment

Uh oh!

cgundogan commented Jan 29, 2019

Uh oh!

miri64 commented Jan 29, 2019

Uh oh!

miri64 commented Jan 29, 2019

Uh oh!

aabadie commented Jan 30, 2019

Uh oh!

miri64 commented Jan 18, 2019 •

edited

Loading

maribu commented Jan 19, 2019 •

edited

Loading

miri64 commented Jan 25, 2019 •

edited

Loading