-
Notifications
You must be signed in to change notification settings - Fork 420
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
Add IEEE 802.15.4/6LoWPAN support #469
Conversation
Very interesting! ieee802154/6lowpan support would be definitely great to have in smoltcp, but it's not a small task :) I believe the 6lowpan frame format is quite different than standard ipv6, so it might be a separate wire Packet and emit/parse methods. Support could be added in There's also 6lowpan over BLE (bluetooth low energy), which would use 6lowpan but not ieee802154 framing, passing the 6lowpan frames to a separate BLE stack. How "independent" is 6lowpan from ieee802154? It would be great if it could be implemented at a layer lower than |
6lowpan needs to set the addresses in the ieee802154 header (ieee802154 doesn't really do a lot, it has a sequence number per frame, and the source/destination address/pan ID and some security feature). The problem with 6lowpan is that it is hugely interlinked with IP, doing IP layer compression and fragmentation, since ieee802154 only allows 127 octets per frame. It also needs to perform the ARP and NDP, etc. I'm not sure what you mean with your last question. |
Just added 6LoWPAN IPHC parsing in wire, as well as the 6LoWPAN NHC parsing for UDP. |
Most of the wire implementation is done (need some more work on resolving the Address and probably other stuff that will come up when implementing the higher layers). Currently, only IEEE 802.15.4 addresses are used (and thus not the BLE addresses). I think I now understand your last question. I think 6LoWPAN also needs to handle the ARP and NDP. |
Hi @Dirbaio, I think the wire part is mostly done (probably still needs some more tests etc.). |
The current state of this PR is that I can use UDP sockets over 6LoWPAN for receiving. |
6de56b0
to
5a477ed
Compare
OK, still need correct some tests :'-). |
This is so cool! How do you test it out? Is there a way to create a "6lowpan tun/tap" to get Linux to talk to it? |
I'm testing it on real hardware. Our research group at the university uses Contiki on Zolertia RE-Motes to research protocols used in IEEE802.15.4. Now we are starting to test protocols written in Rust. The tests I have are really not that great yet: using a Contiki implementation + using a Rust implementation + an IEEE802.15.4 sniffer... |
Fun! It seems like it should be possible to get it going with fakelb (now deprecated? the replacement is ieee82154_hwsim?): https://www.netdevconf.org/2.1/slides/apr8/aring_virtual_mesh.pdf |
It seems so that ieee82154_hwsim with wpan-tools is the way to go for testing, however my knowledge about those tools (especially modprobe, ip, etc.) is non-existent. |
I've got hwsim working! I've pushed it to your branch (hope you don't mind). The I've tried pinging it (with |
Thank you for the test! I didn't test NDISC, since I manually added the neighbour address into the cache in my tests. |
14d553e fixes the addressing issue. I'll now try to adapt ICMP for 6LoWPAN (uncompressed version). |
|
f246229
to
5ed4d4a
Compare
Rebased on master. 1 test is failing but I have not yet figured out what causes this. |
Apparently the UDP API has changed, so need to update the Sixlowpan part. |
This avoids wire needing to know what medium we're on.
Equivalent of 6210612 for 6lowpan
We assume the FCS is checked by lower layers or by hardware. - Makes it consistent with Ethernet mediums, where we don't handle the FCS either. - Linux ieee802154 raw sockets send/receive packets without the FCS.
Using a raw socket on `monitor0` causes weird results: packets we receive include FCS, packets we send are parsed as if they didn't have FCS, except by wireshark which always expects a FCS?? Turns out the sane way is to use raw sockets on normal `wpanX` interfaces, in which case all packets we send/receive are without FCS.
Also check for the correct destination PAN id when receiving a frame (as discussed). Linux does this as well. However, hardware implementations also can drop those packets.
When there is no medium in the feature flags, then there is no HardwareAddress.
Not adding to `defmt` because it doesn't build yet.
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.
@thibautvdv I'm going to merge this. It's complete, works great, code is well structured! 👍 The few remaining TODOs don't seem very critical, they can be addressed in future PRs.
I want to do some big changes to Interface code, which would send this to conflict hell otherwise.
bors r+ |
This adds the IEEE 802.15.4 frame representation.
Still a work in progress and interested to know what you think about this.
I really would like to add 6LowPAN as well, however I'm not sure where to put this in smoltcp, since 6LowPAN is kind of weird.