A few days ago I asked about an OSI layer 3 interface for reticulum because the interfaces in the reference implementation that go over Ethernet/WiFi are all implemented on top of protocols that use IP. I asked if there were any good reasons why one isn't provided, and if not I would try writing my own. Well I wrote my own prototype (hosted on Codeberg here), and in the process I think I've answered my own questions.

In order to write a layer 3 protocol in user space, I had to create a layer 2 socket to read the Ethernet frames. In Linux, you can only do so as root, so my implementation has to be run as root, which comes with a bunch of its own issues. Separate to the must-be-run-as-root issue, since I'm reading the raw Ethernet frames, the socket my Python script creates bypasses the Linux kernel's normal routing of traffic on that network interface. This means all traffic on that interface is routed to the Python script, so if you want to use that hardware interface for anything else besides reticulum traffic, the Python script will block that (it drops frames it doesn't recognize).

From what I can tell, the standard way to do all of this in Linux is to write a kernel module that registers packet routing functions with the kernel for handling the Ethernet frames associated with your protocol, and then those kernel module functions will pass the data to the right process in user space. I'm guessing Mark Qvist weighed the pros and cons of requiring a kernel module and opted for implementations on top of protocols already provided in the Linux kernel (and other OS kernels) to make it as easy as possible to get started. But now that there's a solid community around reticulum, I don't see a reason we couldn't write a kernel module and a new interface that uses it (if available), so I'm going to give that a try over the weekend. Given the packet structure and routing architecture of reticulum, I think there's actually very little code that must go in the kernel. I'll see how far I can get.

Hi all. I'm new to reticulum, having found it about 2 weeks ago. I am a software engineer by trade, so it wasn't too big of a learning curve to jump into. I have rnsd and nomadnet running on a pair of Linux devices, RNode running on a pair of Lilygo T-Echo radios to test LoRa with, and I managed to cross-compile rns-rs and get its version of rnsd running on my OpenWRT router (which is an ARM64 architecture with musl for libc, which presented some headaches). My router vendor doesn't provide pip or the cryptography Python library as installable packages, so rather than muck about with firmware and potentially break my home network entirely, it seemed less risky to compile a binary with minimal dynamic libraries to link and run that. Seems to work.

I have read through the Zen of Reticulum, particularly the Death to the Address section, and I interpreted that as a project goal to replace the Internet Protocol (i.e. IP), a layer 3 protocol in the OSI model. The Hardware section of reticulum.network also seems to jive with that interpretation, as "Any ethernet device" is listed separately from "TCP over IP networks" and "UDP over IP networks."

However, when I read through the Configuring Interfaces section of the manual, all of the options for Ethernet/WiFi seem to be built on top of either TCP or UDP, which are themselves built on IP. The AutoInterface uses UDP, the BackboneInterface uses TCP, there are specific TCP and UDP interfaces, and then everything else seems to be for more specialized connections (RNodes, serial connections, amateur radio, etc.) or compatibility interfaces with other cryptographic or anonymization protocols (I2P and Yggdrasil). Am I missing something?

I'm not a low-level network programmer, so I am definitely out of my element here and wanted to check with others who may be more knowledgeable in the domain. I have done some reading on building Ethernet frames and was planning to try my hand at writing some kind of EthernetInterface using the Custom Interfaces API, but if there's a reason such an implementation doesn't exist, and I would be wasting my time, I wanted to ask. I was planning to do a Python implementation as a prototype and then write an extension to rns-rs to try on my router.

Update : Small update. I have a prototype Python implementation working on my home devices. There's a big caveat to my implementation: in order to get access to raw Ethernet frames required by this interface, rnsd needs to be run as root. This makes sense to me because differentiation of network traffic data packets is typically handled by TCP and UDP sockets, so layer 4. I'm doing a layer 3 implementation, so working with layer 2 data, where we have no differentiation of what owns what data, so it has to be handled by root (and honestly should probably be handled in the kernel). This appears to require other processes that want to share the transport instance (e.g. NomadNet) to run as root as well, but I could be doing that part wrong. If any of my reasoning is flawed here, please let me know! Otherwise, I need to clean up error-handling and then I'll post my code on a new repository on Codeberg.