Level of effort getting started with 6LoWPAN (Thread) using libtock-rs?

[potto216]

Hi, what is the level of effort needed to create a toy application using libtock-rs on a board demonstrating basic 6LoWPAN communication with compressed UDP headers? The end goal would be a toy application showing Thread. I'm willing to live with the "Showstopper bug" that prevents the generation of relocatable code for userland Rust.

I saw the documentation for the network stack and the 6LoWPAN capsules. But the only board code examples I found are for the IMIX board such as ipv6_lowpan_test.rs but it doesn't appear the IMIX is available for purchase.

Boards such as the RF52840 DK which have OpenThread and TockOS along with 802.15.4 TockOS code support suffer from possible show stoppers such as the NrF52 crypto issue

Is there a recommendation of a board that is available for purchase that supports some basic 6LoWPAN features in userland Rust? Thanks! --Paul

[hudson-ayers]

Hi, thanks for this detailed question. I am probably the Tock developer with the most experience using the current 6LoWPAN stack, I'll do my best to describe the current state of affairs.

Getting a toy application using libtock-rs demonstrating basic 6LoWPAN with compressed UDP headers should be doable. Getting a toy application working does not require any working crypto implementation (by default we send unencrypted 15.4 messages). Therefore, any of the nrf52 boards will work well, as the Nrf52 crypto issue can just be ignored. I would recommend the nrf52840dk as it is easy to obtain and is what I have used in the past to test 6LoWPAN applications in libtock-c.

Therefore the main problem you will face is just that libtock-rs does not have any networking support currently. So you would have to port the libtock-c networking code over to libtock-rs. Fortunately, the vast majority of the 6LoWPAN logic is hidden in the kernel, so this port will be relatively straightforward.

While you are correct that the only in-kernel 6LoWPAN tests are for the Imix board, I have tested the Imix and Nrf52840dk extensively using the libtock-c UDP applications, and UDP-over-6LoWPAN is enabled by default for the nrf52840dk kernel (as well as the nano33ble if that is easier for you to obtain or if you need a richer suite of sensors or smaller form factor).

Now to address a few other points in your question:

The end goal would be a toy application showing Thread.

It has been a few years since I looked at Thread, but last I checked there was a huge amount of effort required to go from a working 6LoWPAN stack to a working Thread application. Tock does not have in-kernel Thread support, and I believe it would be a lot of work to implement. Alternatively, you could try to implement Thread in userspace, perhaps using the existing OpenThread code. This has approach has two potential problems:

1. I am not sure whether the existing userspace APIs would be sufficient to do so, in fact I suspect additional APIs that interface directly with the 6LoWPAN layer might be needed, and I am not sure how much effort they would be to implement.
2. If you do want to use existing OpenThread code, you're probably better off using libtock-c anyway, since I don't know of any Rust Thread implementation that isn't just bindings to call into Openthread.

Boards such as the RF52840 DK which have OpenThread and TockOS along with #1878 suffer from possible show stoppers such as the #994

If you do in fact require crypto support, as this comment somewhat suggests, I agree that you are better off not using an nrf52 based board, as hardware accelerated cryptography support is not on any near-term timeline for that chip in Tock. Unfortunately the only Tock chips with 802.15.4 support are the Sam4l (used in the no-longer-for-sale Imix and Hail) and the nrf52840. If you need a board with hardware-accelerated crypto support + still believe that Tock represents a good target for your efforts based on the above description, let me know, and we can connect to talk about a way for me to send you an Imix.

[potto216]

@hudson-ayers thanks for the great answer. Porting the libtock-c networking code to libtock-rs seems doable if the level of effort is udp.c and ieee802154.c. The purpose of the toy problem with 6LoWPAN is to share with members of the meetup I belong to (Charlottesville Rust Meetup)[https://www.meetup.com/Charlottesville-Rust-Meetup/] how to do embedded wireless with Rust using a Rust based OS. Therefore, encryption isn't that big of a deal and Thread can wait. The bigger issue is the cost and availability of the development board so I think the Nrf52840dk is a good choice. Would the next step be for me to create an issue on the libtock-rs repo?

[hudson-ayers]

Porting the libtock-c networking code to libtock-rs seems doable if the level of effort is udp.c and ieee802154.c.

Technically the only part of ieee802154.c you would actually need to port for a toy example is the functionality for setting the mac address, the rest is unneeded for the UDP examples. You would need to port all of udp.c

Would the next step be for me to create an issue on the libtock-rs repo?

Sure, you could create an issue on the libtock-rs repo, though I don't know that I would expect any Tock developers to take that task on soon. The best approach would be if you could submit a PR to libtock-rs that gets at least most of the way there, and then @jrvanwhy and myself can hopefully help get the port the rest of the way. One challenge with writing libtock-rs drivers is that we recently revamped libtock-rs for the Tock 2.0 system call interface, and have not yet written comprehensive guides on how to write userspace drivers. @jrvanwhy can hopefully point you toward the best example to start from

[potto216]

Okay thanks, I'll fork the libtock-rs repo and work on a PR and then go from there!