Add IEEE 802.15.4/6LoWPAN support #469

thvdveld · 2021-04-29T10:21:28Z

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.

Dirbaio · 2021-05-02T19:43:00Z

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 Interface, with a new Medium variant.

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 Interface instead of inside Interface itself, but I'm fearing that may not be possible, like with Ethernet. Ethernet support is super interlinked with IP, since it has to do ARP and NDP and silence the sockets until neighbors are discovered, etc. I tried splitting it in #336 and the result wasn't pretty. Is there similar neighbor discovery / MAC addressing issues with 6lowpan over ieee802154?

thvdveld · 2021-05-03T07:17:28Z

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.

thvdveld · 2021-05-08T16:17:00Z

Just added 6LoWPAN IPHC parsing in wire, as well as the 6LoWPAN NHC parsing for UDP.

thvdveld · 2021-05-12T11:05:02Z

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.

thvdveld · 2021-05-18T06:55:37Z

Hi @Dirbaio, I think the wire part is mostly done (probably still needs some more tests etc.).
I started in interface.rs but then I was wondering what the best approach was.
Would you handle each LOWPAN packet with new functions or should we first convert the incoming LOWPAN packet to an IPv6 packet and then handle it with the already existing functions?
The response is then converted back to a LOWPAN packet before sending it to the lower layers.
Not sure what the best approach is here.

thvdveld · 2021-05-28T15:04:55Z

The current state of this PR is that I can use UDP sockets over 6LoWPAN for receiving.
Sending is also possible although only when an address is manually added to the neighbour cache.

thvdveld · 2021-05-28T15:31:53Z

OK, still need correct some tests :'-).
The next step is probably updating ICMP and NDP since 6LoWPAN also has it's RFC for that...

Dirbaio · 2021-05-28T15:40:13Z

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?

thvdveld · 2021-05-28T15:48:01Z

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

Dirbaio · 2021-05-28T17:21:52Z

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

thvdveld · 2021-05-28T19:56:49Z

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.

Dirbaio · 2021-05-29T03:31:36Z

I've got hwsim working! I've pushed it to your branch (hope you don't mind). The sixlowpan example has the commands to set it up. Once it's running it sends/receives packets to the Linux 6lowpan stack, so you can talk to it with regular Linux ping etc.

I've tried pinging it (with ping fe80::180b:4242:4242:4242%lowpan0) but it seems the ICMP checkum fails because IPHC doesn't decompress to the right dst addr (smoltcp says fe80::00ff:fe00:ffff, wireshark says ff02::1:ff42:4242. it's a broadcast Neighbor Solicitation)

thvdveld · 2021-05-31T10:02:38Z

Thank you for the test!

I didn't test NDISC, since I manually added the neighbour address into the cache in my tests.
The reason why I didn't test it yet is because the Contiki stack uses the compressed version of ndisc (which I didn't implement yet for smoltcp). However, 6LoWPAN should be able to work with uncompressed formats of ndisc. I'll try to debug the example now.

thvdveld · 2021-05-31T12:53:59Z

14d553e fixes the addressing issue. I'll now try to adapt ICMP for 6LoWPAN (uncompressed version).

thvdveld · 2021-06-08T15:11:10Z

ping should now work. Next step is to polish the code a little since a lot is still spaghetti code.

thvdveld · 2021-08-18T10:03:31Z

Rebased on master.

1 test is failing but I have not yet figured out what causes this.

thvdveld · 2021-08-18T13:27:18Z

Apparently the UDP API has changed, so need to update the Sixlowpan part.

Cargo.toml

src/dhcp/clientv4.rs

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.

Dirbaio

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

Dirbaio · 2021-10-20T23:46:34Z

bors r+

bors · 2021-10-20T23:50:55Z

Build succeeded:

thvdveld force-pushed the ieee802154 branch from 007d0cd to bcda752 Compare May 25, 2021 17:25

thvdveld force-pushed the ieee802154 branch 2 times, most recently from 6de56b0 to 5a477ed Compare May 28, 2021 15:14

thvdveld changed the title ~~Add IEEE 802.15.4 frame support~~ Add IEEE 802.15.4/6LoWPAN support May 28, 2021

thvdveld force-pushed the ieee802154 branch 5 times, most recently from f246229 to 5ed4d4a Compare August 18, 2021 10:01

thvdveld force-pushed the ieee802154 branch from 5ed4d4a to 6bb0cff Compare August 18, 2021 10:08

thvdveld force-pushed the ieee802154 branch from 4a5a0aa to 380df10 Compare August 18, 2021 14:52

Dirbaio reviewed Sep 8, 2021

View reviewed changes

Cargo.toml Outdated Show resolved Hide resolved

Dirbaio reviewed Sep 8, 2021

View reviewed changes

src/dhcp/clientv4.rs Outdated Show resolved Hide resolved

thvdveld and others added 21 commits October 21, 2021 01:25

Add support for 802.15.4 and 6LoWPAN

3d782f1

Add RawHardwareAddress, use it in wire ndisc.

68e25a2

This avoids wire needing to know what medium we're on.

wire: remove HardwareAddress::BROADCAST

102db1d

ipv6: fix Solicited Node address calculation

4b1de11

6lowpan: do not fill neighbor cache from random packets

cd40acb

Equivalent of 6210612 for 6lowpan

ieee80154: process packets without the FCS.

bdd09c4

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.

phy: Use right protocol on RawSocket based on the medium.

f35e760

Use one PAN ID for source and destination

f67f024

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.

Use net_debug and drop instead of todo!

7bad4cf

Send ICMP unreachable when no UDP socket is found

aed9fdb

Set HardwareAddress behind feature flag

3c49822

When there is no medium in the feature flags, then there is no HardwareAddress.

Defmt for RawHardwareAddress

2de8b7a

Remove some more todos

954a757

Set flags to zero, because buffer could be reused.

0c39c50

Remove IpRepr::Sixlowpan

ddfd6f8

ieee802154: ignore frames with types other than Data

d8e7b7a

ieee802154: Correct filtering of PAN id

0e3b668

ieee802154: update documentation

9fecf50

ieee802154: log when we drop a frame

aeca423

Fix some comments.

5e7e75a

Dirbaio force-pushed the ieee802154 branch from fd5366f to 5e7e75a Compare October 20, 2021 23:32

Dirbaio added 2 commits October 21, 2021 01:38

Add medium-ieee802154 to CI.

d5b2c75

Not adding to `defmt` because it doesn't build yet.

Fix build when setting medium-ieee802154 but not proto-sixlowpan.

bc2934d

Dirbaio marked this pull request as ready for review October 20, 2021 23:43

Dirbaio approved these changes Oct 20, 2021

View reviewed changes

bors bot merged commit c8141bb into smoltcp-rs:master Oct 20, 2021

jacobrosenthal mentioned this pull request Nov 12, 2021

nrf: add initial support for CLOCK and RADIO embassy-rs/embassy#463

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add IEEE 802.15.4/6LoWPAN support #469

Add IEEE 802.15.4/6LoWPAN support #469

thvdveld commented Apr 29, 2021

Dirbaio commented May 2, 2021 •

edited

thvdveld commented May 3, 2021

thvdveld commented May 8, 2021

thvdveld commented May 12, 2021

thvdveld commented May 18, 2021

thvdveld commented May 28, 2021

thvdveld commented May 28, 2021 •

edited

Dirbaio commented May 28, 2021

thvdveld commented May 28, 2021

Dirbaio commented May 28, 2021

thvdveld commented May 28, 2021

Dirbaio commented May 29, 2021

thvdveld commented May 31, 2021

thvdveld commented May 31, 2021

thvdveld commented Jun 8, 2021

thvdveld commented Aug 18, 2021

thvdveld commented Aug 18, 2021

Dirbaio left a comment

Dirbaio commented Oct 20, 2021

bors bot commented Oct 20, 2021

Add IEEE 802.15.4/6LoWPAN support #469

Add IEEE 802.15.4/6LoWPAN support #469

Conversation

thvdveld commented Apr 29, 2021

Dirbaio commented May 2, 2021 • edited

thvdveld commented May 3, 2021

thvdveld commented May 8, 2021

thvdveld commented May 12, 2021

thvdveld commented May 18, 2021

thvdveld commented May 28, 2021

thvdveld commented May 28, 2021 • edited

Dirbaio commented May 28, 2021

thvdveld commented May 28, 2021

Dirbaio commented May 28, 2021

thvdveld commented May 28, 2021

Dirbaio commented May 29, 2021

thvdveld commented May 31, 2021

thvdveld commented May 31, 2021

thvdveld commented Jun 8, 2021

thvdveld commented Aug 18, 2021

thvdveld commented Aug 18, 2021

Dirbaio left a comment

Choose a reason for hiding this comment

Dirbaio commented Oct 20, 2021

bors bot commented Oct 20, 2021

Dirbaio commented May 2, 2021 •

edited

thvdveld commented May 28, 2021 •

edited