I would link to my last post, but I don't know how to do that so that it works cross instance. I have two older posts with the same title (first one without the [Update] portion), so they should be easy to find on your local instance.

So I underestimated the differences between user-space software development and developing for the kernel. "This weekend" became 4 months, largely while I had to learn how to find information. I had several false starts, the most costly of which was trying to understand and mirror the IP stack. That was way more complicated than I needed, and abandoning trying to hook into the sockets API made the result much more manageable. I settled on a custom character device, /dev/rns, that user-space programs open a regular file descriptor with. They then use read() to receive messages and write() to send them, and ioctl() calls set Reticulum-specific metadata, like a program's Reticulum destination address.

Anyway, today I finished the MVP. I've put it up on Codeberg here. It does the minimal possible to meet the requirements of "over Ethernet and not on top of IP," so there are several known issues and limitations I'll discuss at the end. It's also still very experimental, so the installation process is still rough. I'll put the details in a separate section as well, but the basic summary is four steps: build and install the module, install the Python interface file for the reference Python-based Reticulum rnsd to use, update your rnsd configuration to use the custom interface, and run rnsd either as root or a user in a special group with a specific capability (detailed in the setup instructions).

Its limitations means you probably shouldn't use it as your daily-driver Reticulum interface, but I hope to get it to that level very soon. My next steps are to see if I can get it to integrate with rns-rs so I can run it on my OpenWRT router and get my multi-router home network setup. And long term I want to have as much of a full rnsd implementation in the kernel module as possible, so that it can efficiently handle routing, MAC addressing, and other parts.

If anyone is interested in working on this with me, please let me know! I would love to have others on this project with me!

Installation

Prerequisites: You will need the Linux kernel headers for the version of the kernel your desired destination system is running, a C compiler, and make. You will need root permissions on the destination system in order to load the kernel module and either run rnsd as root or configure the system so that you can run it rootless.

1. Clone the repository and build the kernel module with make. Do not install it at this stage unless you plan to run it as root.
2. (Optional; for rootless usage) Run the install.sh script to create a new group, called rns-net by default, and a udev rule to set the /dev/rns node ownership and permissions for group access when the device node is created by installing the kernel module.
3. Install the kernel module with sudo insmod rns.ko.
4. (Optional; for rootless usage) Run the install-service.sh script to create a systemd service for your existing Python rnsd program. This gives it the CAP_NET_RAW capability at run time as an alternative to giving the Python interpreter the capability permanently, which is a greater security risk.
5. Install the KernelEthernetInterface.py file in your (or root's) ~/.reticulum/interfaces directory, and update your (or root's) ~/.reticulum/config file following the example.
6. Start the rnsd executable either with the systemd service for rootless execution (sudo systemctl start rns) or as root.

Limitations and Known Issues

The upside to this module is it's not like other Reticulum interfaces that take a bit of configuration and some specialized knowledge (other than building and installing the kernel module, but I plan to simplify that process dramatically in the future). The configuration is setting some rnsd fields (type and enabled) and then setting the network interface you want it to use. That's it. With that, I didn't need a backbone on the network for UDP discovery or anything. My two test devices just found each other; running NomadNet on both was kind of magical in that respect.

That being said, there are quite a few issues. One is, since the kernel module isn't doing the routing, all packets are addressed to the MAC broadcast address, so all other devices on your network have to determine if the packet is meant for them. Another limitation is that, since I picked an arbitrary unused Ethertype value, no network equipment that's not running this module will understand what that traffic is, and will likely drop it. That means it's local network only; your ISP won't understand it and will drop it.

Finally, I took some shortcuts on the implementation, intending to flesh it out later. IFAC is completely unsupported, and because of that and a lower limit on the size of valid Ethernet frames, very small packets will have zero-pad bytes at the end that will likely make them unintelligible to the reference rnsd. I think this will only apply to unencrypted packets, which are an extremely niche case, so I don't think you will encounter this issue in practice.

The excitement of loading the kernel module on my two test machines and sending messages between them with NomadNet is a feeling I haven't experienced in probably the last 5+ years of my software development career. I will definitely be continuing with this project.