[Update] No Native Layer 3 Interface?
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](https://codeberg.org/ignirtoq/rns-layer3-poc)), 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.
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.