-
Notifications
You must be signed in to change notification settings - Fork 2k
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
sys/net/gnrc: Flag esp_now as 6LN #13561
Conversation
In gnrc_netif_init_6ln() the flag GNRC_NETIF_FLAGS_6LN is accidentally not set for esp_now devices. This commit fixes this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK. Makes total sense.
I'm completely confused now. The output of the long, long discussion in PR #10817 was that ESP-NOW nodes are no "real" 6Lo nodes since they don't have a EUI64 which is required for ARO in 6Lo-ND. Even though, PR #10817 provided a possibility to use the modified EUI64 instead, PR #10499 introduced the distinction between 6LN nodes and 6LO nodes. According to this distinction only 6LN nodes should get the /**
* @brief This interface represents a 6Lo node (6LN) according to RFC 6775
*
* @see [RFC 6775, section 2](https://tools.ietf.org/html/rfc6775#section-2)
*/
#define GNRC_NETIF_FLAGS_6LN (0x00001000U) Neither CC110x nor That's why I never proposed the change in this PR but thought we have to to set the |
I don't know enough about the standard or the previous discussion to draw any such conclusions from it, but intuitively it makes total sense that those wireless technologies should perform neighborhood discovery (and remember what Linus said about standards… 😉) As for separating 6LO and 6ND it makes logical sense to me, even though afaik currently in RIOT everytime we do 6LO we also want 6ND. |
Ok sorry, I forgot about that discussion completely 😞. What you say makes sense. Both of them should due to the hardware address restrictions rather use classic neighbor discovery, or use the converted EUI64 (like IPv6-over-BLE does) in the ARO. |
There no standard for both IPv6 over cc110x or esp-now ;-) We just use 6LoWPAN because it is convenient to re-use existing standards for radios with similar restrictions IEEE 802.15.4 has. |
That said: only because an IPv6-over-X implementation uses 6LoWPAN to make IPv6 over a restricted medium possible (i.e. use its fragmentation and header compression features) does not mean they have to use the neighbor discovery optimizations in RFC 6775 (which are more about power conservation than anything else). If the problem is the missing dissemination of compression context, than we should disable the automatic configuration for those interfaces, i.e. check if the given interface represents a 6LN. |
Yeah, me too 😟 Even worse, since 6LoWPAN is not part of my daily work, I also forgot many details about the mechanisms in 6LoWPAN and their implementation in RIOT. But if I remember correctly, 6Lo-ND simply did not work with ESP-NOW because of the missing EUI64. However, with a small hack using the IID as EUI64 it worked for me (as far as I remember). With the
For me, it sounds like an option. Or would it require to implement something more? |
Huh? Why would the source of the EUI-64 be relevant as to whether the device can use 6Lo-ND? Most radio drivers just call |
Yepp, using |
Because 6Lo-ND's address registration feature (which is used for duplicate address detection) uses the EUI-64 to uniquely identify the nodes. See
Don't mix up the IEEE 802.15.4 EUI-64 (which is a real hardware address) and what typically is understood as an EUI-64 (a 64-bit identifier generated from the real hardware address by the specfied algorithm; this is why your Laptop has an |
@miri64 While looking in RIOT/sys/net/gnrc/netif/gnrc_netif.c Lines 1273 to 1274 in 0b1dce3
IPV6_MIN_MTU ?
|
So for the proprietary link-layers, its probably smart to pick 1500 as MTU, to avoid the need for IPv6 fragmentation on top. |
All right, thank you for the detailed explanation 😄 |
Contribution description
In gnrc_netif_init_6ln() the flag GNRC_NETIF_FLAGS_6LN is accidentally not set for esp_now devices. This commit fixes this.
Testing procedure
Running
ifconfig
inexamples/gnrc_networking
e.g. on theesp8266-esp-12x
shows no IPv6 address with master. With this PR, the address should show up again andping6
ing should work.Issues/PRs references
same as #12683