-
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
gnrc_netif: add general IID to/from l2addr conversion functions #10513
gnrc_netif: add general IID to/from l2addr conversion functions #10513
Conversation
b20cdb4
to
80258ef
Compare
Rebased to current master and new dependencies. |
…c_netif_hdr/enh/conv-iid-getter
c618ccd
to
b2a05a5
Compare
Rebased to and adapted for current master (since the #10514 dependency actually requires a PR downstream from this PR - #10514 (comment)). Ready for review and testing. |
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.
Looks good to me code-wise :-)
I hope I can test it tomorrow with the |
To me it looks like the current issue Murdock uncovered seems to be unrelated. @cladmi: As far as I know you are a linker magician. Care to have a look at the murdock build log?
This does not seem to be an overflow, as in case of an overflow I get a message like this:
(I cannot recall how the message looks like in case of a RAM overflow, but I assume it will also use the phrase "overflowed by xy bytes".) |
would you mind to rebase? That would simplify the review a bit... Thx |
Back on track: @maribu were you able to test by now? |
To show the output for the On my With this PR:
With a "bigger" RAM,
So the board just needs to be put in |
Works fine with the CC1100/MSB-A2 using the current cc110x driver and works fine with the CC1101/MSB-IoT using PR #10340 |
@gschorcht can you test with ESP32? |
Works fine with the ESP32 |
Thanks for testing @maribu and @gschorcht! |
I just found my |
You don't have to if you don't have the time. |
@miri64 I forgot to mention, I tested ESP32 only with I have also an ESP32 board with EMAC and LAN8270 ethernet interface. So, I tested it with |
What I'm wondering about ESP-NOW is that for examples its _send function expects the data to be a pointer to an ipv6_hdr_t: https://github.com/RIOT-OS/RIOT/blob/master/cpu/esp32/esp-now/esp_now_netdev.c#L526 But with 6Lo, wouldn't something along those lines be needed, where the first byte of the data indicates what actually follows: https://github.com/RIOT-OS/RIOT/blob/master/sys/net/network_layer/sixlowpan/sixlowpan_print.c#L23 Or is that unpacked for ESP-NOW at an earlier point, and it only gets to see properly fragmented actual IPv6 packages? |
But to answer your question: yes ESP-now needs then to assume, that the first header is a 6Lo dispatch instead of a IPv6 header. |
(this whole file looks rather hacked I might add oO) |
tested all remaining link layers successfully:
|
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
They are required to make GNRC's 6Lo IPHC implementation ready for hardware addresses other than IEEE 802.15.4's.
0535402
to
bc1b490
Compare
Squashed |
Marked |
c7d146d
to
f757376
Compare
all green -> go! |
Contribution description
They are required to make GNRC's 6Lo IPHC implementation ready for hardware addresses other than IEEE 802.15.4's.
Testing procedure
Pinging a link-local address with
gnrc_networking
should still work forIssues/PRs references
Depends on
#10509(merged),#10514(invalid dependency), and#10515(merged).