Porting to C

[OxMarco]

A question more than an issue.
Can Reticulum be ported to C? It would benefit all those uC like the ESP32 or the NRF52840 that power many low power LoRa transceivers. Micropython is quite expensive CPU-wise and increases power consumption.
What are the main problems to be faced when porting it to C? I can do it myself but I'll need support throughout the process.

[markqvist]

Yes, it can, and it will, given that I have the resource to do it. It has always been my intention to create a version in C. When I have added the last few features to the Python reference implementation, and I lock in the API, I will start work on the C implementation.

[markqvist]

Also, I would very much appreciate help on this endeavour, so if you want to join in, you are very welcome.

I do however think it’s necessary to wait until the Python implementation is done, the API has been locked in, and the documentation has been completed.

[OxMarco]

Okay ping me once you're ready to create the C version. I've listed some interesting ideas on the Meshtastic forum.

[OxMarco]

Are you still maintaining it?

[blademaster98]

Are you still maintaining it?

hard to tell , no updating since last August. Let's find out is there anything we can do?

[OxMarco]

Well first of all check if the current version is reliable enough to be used, then start porting it to C using a proper HAL in order to support as many embedded platforms as possible.

[blademaster98]

Well first of all check if the current version is reliable enough to be used, then start porting it to C using a proper HAL in order to support as many embedded platforms as possible.

sounds like a plan

[markqvist]

I am still very much maintaining Reticulum. Life has not been too generous with time lately though, and I've had to focus on things more related to survival than passions. Although I had a goal of having Reticulum in an API-stable beta release by the first day of 2021, it did not pan out that way, and I was severely delayed. Things have calmed down for me now though, and for the next few months, I should be able to complete that work.

I'd really strongly suggest against starting a C-port right now. There's still a few crucial details that need locking in, and doing this without the API documentation I'm currently writing would be a frustrating experience.

I would very much appreciate the help once it is time, but please have just a little more patience :) I know it's been a long wait, but it will be worth it very soon.

[markqvist]

And in the meantime I am open for any discussion on the matter in this thread. I will be available to answer questions and discuss it here.

[blademaster98]

And in the meantime I am open for any discussion on the matter in this thread. I will be available to answer questions and discuss it here.

How nice, happy to know you were back. It's ok, we will wait for your docs and lock in the few crucial details

[markqvist]

Hello everyone who is still listening here. Today, I released Reticulum 0.2.0. This is the first release marked as being in beta state. This also means the API documentation and manual has been published at: https://markqvist.github.io/Reticulum/manual/.

In a sense, one could at this point start writing a C port. In the service of being as transparent as possible, I will have to say that I am planning a very big change to the internals of Reticulum though, which will greatly impact any implementations.

I am 95% sure that I will change Reticulum to completely use Elliptic Curve Cryptography on Curve25519 for all assymetric cryptography operations. This will mean RSA is no longer needed, which has been a very limiting factor in the project so far. By using Ed25519 signatures and X25519 ECDH key derivation instead of RSA, protocol overhead will be greatly reduced, and security will be staggeringly enhanced. It really seems like a win-win, but when I worked on the theory behind Reticulum 5 years ago, I didn't know enough about elliptic curves to utilize them confidently, and as such chose to go with RSA-1024 instead.

I'm currently researching the last 5% of doubt I have about this decision, and one of the topics I'm looking into is the feasibility of running X25519/Ed25519 on low-power MCUs and what C implementations exist.

I am very interested to hear anyones thoughts on this.

[OxMarco]

Hey, first of all nice to have you back and to see Reticulum is under development.
Elliptic curves are perfectly supported by most embedded platforms, there are tons of libraries for Arduino, ESPxxx and other popular uC with limited computing resources.
I'm a bit confused by the retransmission parameter m, why don't you append it to the message itself so that other nodes can check how many times it has been rebroadcasted?

Going to the actual task of porting it to C, we need to define some common guidelines beforehand, such as using size-constrained integers (uint16_t, int32_t, ...) and possibly avoid float and double values that may lead to rounding and endianness problems.
Another part of our preliminary analysis would be to check how many dynamically allocated vectors have been used in the Python code, generally for embedded systems there should always be a well-defined max value to preserve system stability.
Finally, as we want to make it as general as possible, I'd recommend using a RTOS (ChibiOS, FreeRTOS, ...) to handle threading and parallel tasks.

[markqvist]

The m parameter is not appended into the message, because it is already there in the header field ;) Byte two of the header field is the "hops" byte, which tells how many hops a packet has taken, which is also true for announces. I updated the "wire format" section in the manual to make it more clear.

Ok, I just finished moving everything to elliptic curves. Was actually a lot less work than I had anticipated. And as you say, it seems there is good support on microcontrollers and in C, so this is going to be the way forward. Protocol overhead has also been greatly reduced now. It's all very, very nice.

What you're saying regarding locking in the typing definitely makes sense, as does having a way to control dynamic vector allocation. I'm going to take a break for a couple of days now, cause I'm literally exhausted ;) When I start again, I will start mapping out the outline of the C version.

I'm quite hesitant to use a RTOS, since I've been down that road before a long time ago, and in the end it ended up being much more hassle than help. My current stance is that making the C port as dependency free as possible is the way to go. We'll need crypto libraries, yes, but that should be more or less it. Task scheduling and async io should be possible with an internal job handler, since the internal "transport machine" of Reticulum is actually pretty simple. You're welcome to convince me otherwise though :)

[blademaster98]

Happy to hear that. I am here still listening

[OxMarco]

Ok moving forward, I've created a pull request to act as WIP for us all. Other general things we need to think about before starting are:

• inline logging: Serial print, file log, other?
• classes: do we keep them or use a purely functional C-style?
• string and number manipulation: any good replacement for native Python libraries?

Small OT: have you seen the Helium project (www.helium.com)?

[rafael2k]

That is really cool! C rocks!

[markqvist]

Yes, you can't imagine how long I have been looking forward to getting this ball rolling :)

[attermann]

Just recently found Reticulum. Very compelling project. Amazing that you've done all of this solo @markqvist. I'd love to be able to help push the µRNS effort along. Nice to see @ellenhp tackling the rust implementation. I assume the plan is to still have a C/C++ implementation as well, is that right? If so and you still don't have the bandwidth yourself I'd be willing to take a stab at it. Just want to be sure I wouldn't be stepping on any toes.

[Erethon]

Also meant to ask; is there a better forum for discussing this than this thread? A discourse or slack channel would be nice (if you don't already have one) to encourage more dialog with the community as things evolve.

There's the matrix channel in #reticulum:matrix.org.

[attermann]

LoRa issue is resolved. After much grief I realized that I had missed setting the preamble length 🤪. I now have a fully autonomous (admittedly incomplete but functioning) MCU LoRa transport node 🎉.

[faragher]

Amazing! There are plenty of people who could find use from a pure repeater even without any other functionality. Well done.

[SebastianObi]

Wow, this is really great. Many people have been waiting for a Reticulm ESP32 transport node for a long time. Now you can operate low-power outdoor LoRa repeaters/nodes. I am waiting for the functional firmware for testing.

[attermann]

OK, if you insist... but remember that you asked for it 😉.

https://github.com/attermann/reticulum-mcu

This is super basic experimental firmware that I'm using on a T-Beam currently, but should be able to be configured for other LilyGo LoRa boards as well without a lot of effort. I was able to use this firmware to bridge two UDP nodes over LoRa by enabling the T-Beam UDP Interface (see README) and send a path request and subsequent data between the two nodes.

It goes without saying that this is very experimental software so all of the usual caveats apply. Looking forward to feedback.

[rafael2k]

Yay, this is just wonderful, a C++ reticulum! I'll test soon in a Raspberry Pi 4 running Linux.
: ))

[ion232]

It's great to see the work that's been done on other implementations of Reticulum. Currently I'm working on an implementation of Reticulum in Zig. For those unfamiliar with Zig - here are some reasons why it's a great choice.

• It's intended to be a better C, which allows it to perform the same functions but with better safety, performance and ergonomics.
• Much of the std library can / will work without requiring a specific runtime like libc, etc, which makes targeting bare metal much easier.
• There's a ZigEmbeddedGroup that maintains microzig, which is essentially an abstraction over embedded devices. There is already support for the RP2040, which I'm planning to target and test on.
• The Zig std library currently has a kitchen sink of various functionality, which includes most of the crypto needed for Reticulum, and I have been using this for now, so that currently I don't need any external dependencies.
• Zig has compatability with C, so C code can be used in Zig, and Zig can be transpiled to C. This means I should be able to directly leverage mbedTLS / OpenSSL, without needing bindings.

The more implementations the better in my opinion.
I'll push up my repo once I have identity working and welcome any thoughts or questions people have in the meantime.

[ellenhp]

About TRNG, are you referring to the fact that the ROSC on the RP2040 isn't necessarily secure enough?

Yep. It's fine for testing but I think they specifically recommend not pulling entropy from it for cryptographic purposes because nobody's really looked at how much of its randomness comes from things that an attacker could predict. Right now I'm targeting an STM32L4 with a TRNG because it's a pretty low cost option. And yeah, nothing against Zig but a lot of people, myself included, see the CoC as woefully inadequate because it only covers interactions in official spaces. So like, sexually harassing another contributor via email is explicitly allowed by the CoC because it covers only official spaces. Also it's against the CoC to discuss the CoC which puzzles me. Lots of weird things, I don't mean to make a point of it but I've been sexually harassed by co-maintainers of FOSS projects before so it's a thing I look for when I engage with a new project or technology.

[markqvist]

Fantastic to hear @ion232! The more languages the merrier! I must say I have no experience with Zig, so I will only be able to provide general pointers and help in regards to the implementation, but feel free to ask any questions that pop up here on the forum, or on the Matrix channel!

But now, the pertinent question... Is it possible to move zig?

[faragher]

But now, the pertinent question... Is it possible to move zig?

You know what you doing.

[xtian]

@ion232 Is your Zig work ready to be public yet?

[ion232]

@ion232 Is your Zig work ready to be public yet?

I'm afraid not, I put it on hold while taking care of other priorities. I do intend to finish it though and get it working on the Pico W. Did you have a particular use case, or just checking the status of it?

[rafael2k]

That is great news!! Right now as a user (hopefully will be able to start helping with code at some point), we support whatever decision to put Reticulum in place running native code!
: ))

[ion232]

I was busy for a while, but there is now also a zig implementation in progress for people to look at and hopefully use not too far in the future. There's a proof of concept that builds an image for the pico. All still WIP.

https://github.com/ion232/reticulum-zig

[MidcoastMedic]

What are the full requirements a board needs to have in order to run micro reticulum on it? I know it works for esp32 like the Heltec V3 but I’m looking for something more conservative on power. It seems Heltec fixed the bug with the Heltec T114 V1 with the new V2. Is the T114 V2 enough for the requirements of a transport node?

[smurfy]

I'm trying to update the "original" transport node to the latest CE firmware, tested on heltec v3 and rak node.

https://github.com/smurfy/RNode_Firmware_CE/tree/transport_node (warning very much in WIP and i do force pushes)

It works, except for what i described here: #767 Thinking about a workarround, clearing the registers did not help, i might reset radio or the whole mcu, till someone smarter than i find the issue in radio code.

Also its fairly battery hungry, so it will need some optimisations otherwise its not really feasable to run as solar node for example.

I also choose to announce on lxmf "app" so it can be seen from other nodes in the network, but since microReticulum is not fully ported yet, writing to the node is not supported yet, but as a transport node its certainly interesting.

Another issue i'm having is i cant get it to compile using the makefile so it needs platform.io for now. (linking errors if -fexceptions is enabled, even without using microReticulum yet.)

[stumpigit]

I've been reading up on Reticulum lately and find porting to C / C++ very important, so that there can also be clients on microcontrollers. Therefore, I have now extended the very well implemented MicroReticulum from @attermann a bit, so that a link can now be established and LXMF messages can be decoded correctly. Here is an example with a T4 S3 board (Lilygo) which receives the message via UDP.

There is still some work to do but I hope I can contribute to the success of this great project! My code is currently in my fork of MicroReticulum: https://github.com/stumpigit/microReticulum/tree/link_support

[smurfy]

@stumpigit i also can say great job, just tested it in my rnode+microreticulum branch and linking and messages seem to work.
Getting delivery confirmations in meshchat. before it hung.

I will do more tests on different hardware too, first test now was on seeed xiao esp32s3, but will test rak and heltec later

[stumpigit]

@smurfy : I did a fork of your RNode firmware and made some customizations so that I successfully got the firmware to run on a Heltec V3. I can write messages in MeshChat, get them decrypted and validated on the Heltec. I still have 37% free heap memory with this one link connection! (currently only via UDP interface, as I only have one Lora device at the moment): https://github.com/stumpigit/RNode_Firmware_CE/tree/transport_node

Somehow I need your explanation though, I probably don't understand something fundamental here. What is the advantage if RNS is integrated in RNode? Theoretically only MicroReticulum would suffice as soon as several interfaces are used?

[cobraPA]

How is this going @stumpigit and others? I'm looking at the various branches and trying some of them out.
For your last question, it's probably just a matter of how to get the Lora framework built with RNS. The RNode code already has the Lora drivers in place, so one option is what atterman did, which is make a fork of RNode firmware and build RNS in to it.

[cobraPA]

It looks like @smurfy did similar, but used RNode_firmware_CE.

[LinuxinaBit]

Somehow I need your explanation though, I probably don't understand something fundamental here. What is the advantage if RNS is integrated in RNode? Theoretically only MicroReticulum would suffice as soon as several interfaces are used?

@stumpigit The idea is that a single interface is treated like two, so you can route things from a LoRa interface straight back out onto that same interface, thus expanding the network without ever involving a separate device running RNS.

[alligitor]

Throwing my 2cents in. As much as it pains me, as a C/C++ developer, Rust would be the right answer for rewrite of Reticulum. There is a lot of push for Rust. Many developers are switching to it, commercial companies are transitioning, etc.
The learning curve is steep though.

[markqvist]

I feel the pain, and I shall thusly stick with C :) Just my own two cents.

Not to dissuade anyone from doing Rust ports, though. You go!

But I'm just going to stay here in my cosy C-shaped armchair. Mmmm. Cccccccccccccccccccc.

[alligitor]

I'll throw another 2 cents in this, mostly because of the following that I just came across:

https://www.cvedetails.com/cve/CVE-2025-24797/

Another memory related, remote code execution type vulnerability.

Rust's claim is to help prevent memory issues. And for a stack like Reticulum that is hinged on security/privacy/etc. makes a lot of sense to nip those types of issues (memory allocation, over write, overflow, blah, blah) in the butt early by using an MSL (Memory Safe Language).

[rafael2k]

C is my comfortable chair too.
: )
Even thou I'm learning go and it does indeed fix some C idiosyncrasies.

[Uberseer]

Rust has a lot of hype (and I understand the benefits), but most comparisons are to OLD C/C++ standards. C++ is not the wild west portrayed by some articles. Also, some of the all-encompassing libraries (like Qt) have done a fantastic job of eliminating the need for pointers, or provide excellent pointer wrappers to greatly diminish the risk associated with pointer use. In that vein, maybe use of the Qt framework with C++ would be a good idea. (They even have ESP32 specific support so their development tools could help accelerate a project).

[ion232]

One issue with Rust is that if you want to use async (and you likely do), then you're often coupled to the async runtime that you choose, unless you manage to very carefully abstract over different runtimes. This is relevant if you want to both support std and no_std (embedded), as you'll be using either tokio or embassy respectively. I've only seen this project successfully abstract over runtimes, and it didn't include embassy. If you try and avoid using async, you'll then run into the issue of being unable to use crates that make use of async functions. That being said, if you decide to pick only std or only no_std, then it's a perfectly good choice.

Personally, I've chosen to use Zig as it's a much simpler language, and I'm pretty sure I can get the same level of safety through extensive testing. An example of which is fuzzing - natively supported by Zig.

I've already mentioned it above, but my implementation is here and continuing to make progress. Current goal is to target WASM and get a node listening to the test net from the browser. WASM also happens to function as an easier way to test freestanding builds than embedded.

[LinuxinaBit]

Just letting y'all know that @attermann is still around; @stumpigit you might want to get in touch ;)

[stumpigit]

Thank you very much for the hint @LinuxinaBit . @attermann also reacted to my comment and made sure that he looked at my implementation (). Unfortunately, he hasn't had time to do so yet. That's why I haven't pursued my development any further, as I think it makes sense to do it in the original MicroReticulum repo. I hope attermann will have time to take a look at it soon. But I know it myself: you often have so many projects to do at the same time...

[disassembledd]

I would like to put a card in for the Rust rewrite club. In my opinion its philosophies better align with Reticulum in terms of security. It also has come a very long way in the embedded world from what people think. I'm unsure "I'm more comfortable with C" is a great way to go about furthering a network stack that I'm sure everyone here wants to see succeed. It would be no different than others in the future saying "I'm more comfortable with IPs and TCP." Besides that, I honestly wouldn't want something this focused on security to, in my eyes, actively take steps backwards.

When I saw the entire project was in Python I was extremely surprised (in a good way). To further ensure the security of the stack, focusing on a language like Rust (or at least Zig) would be extremely beneficial. I feel if a C/C++ port were to happen, the odds of vulnerabilities related to mishandled components of the stack would significantly increase especially as the codebase itself does. Using Rust as an example, implementing a new interface wouldn't have high chances of someone mishandling memory when you can define the trait of an interface strictly and enforce its behavior no matter what it interfaces with.

[LinuxinaBit]

Cool!
Nobody said you had to pick one, in fact you can go help with one of the Rust implementations right now: https://github.com/markqvist/Reticulum/wiki/Awesome-Reticulum#non-reference-and-wip-reticulum-implementations

[ion232]

For what it's worth, I'm also planning to leverage Rust in my implementation for the crypto and possibly the allocator.

[disassembledd]

@LinuxinaBit it feels like that response wasn't in good faith? It's great so many are trying to implement this in different languages and power to them but that doesn't help the future of the stack. Virtually everything that exists has people trying to rewrite it, but only one project stands out as "official" (or actually is official) which is why I chose to message in this discussion specifically.

As much as others try rewrites and whatnot, unless the primary team working on the project (such as Mark himself) agrees and sees vision in it then it does more harm than good. Life will go on if it isn't the direction they choose, I just wanted to voice my opinion so they can see.

[LinuxinaBit]

only one project stands out as "official" (or actually is official) which is why I chose to message in this discussion specifically.

RNS, the Python implementation of Reticulum, is the reference implementation of Reticulum.
That means it is the only “official” implementation of Reticulum, and that is very much on purpose.

As much as others try rewrites and whatnot, unless the primary team working on the project (such as Mark himself) agrees and sees vision in it then it does more harm than good.

The entire point of writing RNS in Python was to make it as portable as possible. Any protocol development will happen in the Python reference implementation, effectively using it as a pseudo-RFC.
This is intentional because Reticulum is, in the end, intended to be a protocol, not a program.

it feels like that response wasn't in good faith?

Yeah, it kinda wasn’t because I’ve gotten a little tired of all the “just use [programming language]” comments. I’m sorry about that.

I just wanted to voice my opinion so they can see.

All good! I hope this helped you see the reasoning behind Mark’s decision.

[disassembledd]

The protocol comment made it click for me. I'm not sure why I didn't view the project as that to begin with. I suppose it's ingrained in me to see an RFC when I'm thinking "protocol specification" and maybe it will be a bit wild west in the start here as people spin off in different languages. It'll be interesting to see what the future holds!

[cobraPA]

@smurfy : I did a fork of your RNode firmware and made some customizations so that I successfully got the firmware to run on a Heltec V3. I can write messages in MeshChat, get them decrypted and validated on the Heltec. I still have 37% free heap memory with this one link connection! (currently only via UDP interface, as I only have one Lora device at the moment): https://github.com/stumpigit/RNode_Firmware_CE/tree/transport_node

Somehow I need your explanation though, I probably don't understand something fundamental here. What is the advantage if RNS is integrated in RNode? Theoretically only MicroReticulum would suffice as soon as several interfaces are used?

I just want to say, good work to the three of you who worked on this so far. I am able to see Lora packets between a Heltec v3 and a T1000-E using your branch mentioned above @stumpigit. Testing to see if it will bridge from wifi to Lora as well soon.

Also, would be nice if the 'I don't think there should be C/C++ implementation crowd' would start a discussion thread for their favorite Rust/Zigg/etc, since this is a C/C++ porting thread. Lots of opinions about what people should work on... Great to see what people want. Make a thread for your favorite language and go to town...

[David-OConnor]

Thoughts on a transparent published spec, so we don't need to worry about language and implementation?

[LinuxinaBit]

I’m sure a Reticulum spec will be more precisely defined when there’s time and when the protocol becomes more stable (note that the manual already defines a wire format etc.), but right now there is just so much going on that it isn’t really worth Mark’s time to deal with that.
RNS is written in Python specifically to support alternative implementations, as it’s fairly portable and easy to understand, so they should be a lot easier to make than if RNS was just a big pile of C.