Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

gnrc_ipv6_nib: use generated EUI-64 for ARO build and check #10817

Merged
merged 6 commits into from
Jan 29, 2019

Conversation

miri64
Copy link
Member

@miri64 miri64 commented Jan 18, 2019

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.

gnrc_netif/gnrc_sixlowpan_iphc BLE capability

@miri64 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 miri64 added this to the Release 2019.01 milestone Jan 18, 2019
@miri64 miri64 changed the title Gnrc netif/enh/i10723 gnrc_ipv6_nib: use generated EUI-64 for ARO build and check Jan 18, 2019
Copy link
Member

@maribu maribu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Found one minor nit and a potential bug

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
@gschorcht
Copy link
Contributor

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

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

@miri64
Copy link
Member Author

miri64 commented Jan 18, 2019

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
Copy link
Member

maribu commented Jan 18, 2019

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

@gschorcht
Copy link
Contributor

I will do it tomorrow.

@miri64
Copy link
Member Author

miri64 commented Jan 18, 2019

Ok, then I rebase now.

@miri64
Copy link
Member Author

miri64 commented Jan 18, 2019

Done

@gschorcht
Copy link
Contributor

👍 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
Copy link
Member Author

miri64 commented Jan 19, 2019

Nope

@miri64
Copy link
Member Author

miri64 commented Jan 19, 2019

(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
Copy link
Contributor

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
Copy link
Member Author

miri64 commented Jan 19, 2019

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

Copy link
Contributor

@gschorcht gschorcht left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK from my side

@gschorcht
Copy link
Contributor

Should we have tests for all candidates?

@miri64
Copy link
Member Author

miri64 commented Jan 19, 2019

Should we have tests for all candidates?

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

@maribu
Copy link
Member

maribu commented Jan 19, 2019

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
Copy link
Member Author

miri64 commented Jan 19, 2019

(but that was expected).

Why?

@miri64
Copy link
Member Author

miri64 commented Jan 19, 2019

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
Copy link
Member

maribu commented Jan 19, 2019

(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.

Copy link
Member

@cgundogan cgundogan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

{
const unsigned offset = sizeof(eui64_t) - addr_len;

memset(eui64->uint8, 0, sizeof(eui64->uint8));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why did you not use an assignment statement here?

eui64->uint8[0] = 0x00;

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

mhm, true (: never mind then

@miri64
Copy link
Member Author

miri64 commented Jan 25, 2019

@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 ;-))

@miri64 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
Copy link
Member

@cgundogan cgundogan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@cgundogan
Copy link
Member

ah, and please squash

@miri64
Copy link
Member Author

miri64 commented Jan 29, 2019

Squashed

@cgundogan cgundogan merged commit b3843da into RIOT-OS:master Jan 29, 2019
@miri64 miri64 deleted the gnrc_netif/enh/i10723 branch January 29, 2019 22:11
@miri64
Copy link
Member Author

miri64 commented Jan 29, 2019

@aabadie @emmanuelsearch shall I backport?

@aabadie
Copy link
Contributor

aabadie commented Jan 30, 2019

shall I backport?

It's a bug, so yes please!

@miri64
Copy link
Member Author

miri64 commented Jan 30, 2019

Backport provided in #10906

Copy link
Contributor

@aabadie aabadie left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Still no change, re-ACK.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: network Area: Networking CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR Community: Hack'n'ACK candidate This PR is a candidate for review and discussion during one of RIOT's monthly Hack'n'ACK parties Type: bug The issue reports a bug / The PR fixes a bug (including spelling errors)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

gnrc_ipv6_nib: 6Lo-ND EUI-64 checks not portable
5 participants