Reticulum LoRa Transport Node with WIZnet W5500

This project implements a standalone Reticulum Transport Node that connects W5500 Ethernet and SX1262 LoRa within the same Reticulum network.

Unlike a typical LoRa gateway that receives sensor data and converts it into MQTT or HTTP messages, this node forwards Reticulum packets directly between its Ethernet and LoRa interfaces.

       Ethernet LAN / rnsd
              │
            W5500
              │
            RP2350
       microReticulum
              │
          SX1262 LoRa
              │
      Remote Reticulum Nodes

W5500 Ethernet and LoRa are not competing communication technologies. They serve different roles.

• LoRa: Long-range wireless connectivity for remote or infrastructure-free edge locations
• W5500 Ethernet: Reliable and higher-bandwidth backbone or backhaul
• Reticulum: The network layer that connects both interfaces into one logical network

In this project, the W5500 is therefore not simply an Internet interface. It acts as a core infrastructure interface that connects the LoRa network to the existing wired network.

Hardware Components

Software

• microReticulum
  : A C++ implementation of the Reticulum Network Stack designed for embedded systems and 32-bit microcontrollers.
• Reticulum / rnsd
  : Reticulum is a cryptographic networking stack designed to operate across different physical transports, including low-bandwidth links. rnsd runs Reticulum as a persistent service on the LAN side, keeps configured interfaces active, and provides the TCP endpoint used by the W5500-based Transport Node.
• RadioLib
  : RadioLib is a general-purpose wireless communication library for embedded devices, with native support for the SX1262 and other LoRa transceivers.
• Arduino Ethernet Library

Relationship Between Ethernet and LoRa

The firmware registers both the TCP interface and the LoRa interface with the Reticulum Transport system.

tcp_interface.mode(RNS::Type::Interface::MODE_FULL);
RNS::Transport::register_interface(tcp_interface);

lora_interface.mode(RNS::Type::Interface::MODE_FULL);
RNS::Transport::register_interface(lora_interface);

reticulum.transport_enabled(true);

The resulting architecture is:

Ethernet
   │
TCPClientInterface
   │
Reticulum Transport
   │
LoRaInterface
   │
SX1262

The main difference from a conventional IoT gateway is that application data does not need to be converted into JSON, MQTT, or another protocol.

Instead, routing takes place directly at the Reticulum network layer.

Why Use LoRa?

Ethernet provides reliable communication, but only where physical cabling is available.

LoRa provides much longer wireless coverage at lower data rates, making it suitable for locations where wired infrastructure is difficult or impractical.

Typical applications include:

• Smart agriculture
• Forest and environmental monitoring
• Outdoor industrial equipment
• Remote sensors
• Rooftop and tower installations
• Emergency and disaster communications
• Campus and community mesh networks

A simple deployment could look like this:

Remote Sensor ─┐
Remote Node ───┼─ LoRa ─ Gateway ─ W5500 ─ LAN / Server
Remote Node ───┘

LoRa handles the long-range wireless edge, while W5500 provides the stable wired path from the gateway to the local network or server infrastructure.

Reticulum Identity Security: X25519 + Ed25519

One of the more interesting parts of this project is the ability to protect the Reticulum cryptographic identity using an SE050 secure element.

A Reticulum identity is not based only on an IP address or MAC address. Instead, it is backed by cryptographic keys that allow the node to establish secure links and prove its identity.

The identity uses long-term keys with different purposes.

X25519

X25519 is used for key agreement. Its purpose is to allow two nodes to derive a shared secret without transmitting their private keys to each other.

A simplified example is:

Node A Private Key + Node B Public Key
               ↓
        Shared Secret
               ↓
      Encrypted Communication

Both sides can derive the same shared secret while keeping their private keys confidential.

X25519 therefore provides the cryptographic basis for establishing encrypted links or sessions.

Ed25519

Ed25519 is used for digital signatures and identity verification. When a node signs information with its private signing key, another node can use the corresponding public key to verify:

Did this message really come from this identity?
                    +
Was the message modified during transmission?

In simplified terms:

X25519
→ Key agreement for encrypted communication

Ed25519
→ Identity authentication and digital signatures

Together, these keys allow a Reticulum node to have a cryptographically verifiable identity, rather than relying only on a network address.

Why the SE050 Matters

On a typical microcontroller, private keys may be stored in internal flash or a filesystem.

MCU Flash
 └─ identity.key
      ├─ X25519 Private Key
      └─ Ed25519 Private Key

If the flash contents or filesystem are extracted, these long-term private keys may also be copied.

This project uses the SE050 secure element to separate the Reticulum identity keys from normal MCU storage.

             RP2350
               │
        Cryptographic Request
               │
               ▼
             SE050
      ┌─────────────────┐
      │ X25519 Private  │
      │ Ed25519 Private │
      │      Keys       │
      └─────────────────┘
               │
        Private keys do
        not leave the chip

Instead of reading the private keys directly, the firmware asks the secure element to perform cryptographic operations such as:

• Shared-secret calculation
• Digital-signature generation

The SE050 returns the result of the operation while keeping the private key protected inside the secure element.

This significantly reduces the risk of simply copying the node's long-term Reticulum identity by dumping the RP2350 flash.

This is especially useful for gateways installed in physically accessible locations such as rooftops, factories, outdoor cabinets, farms, and remote monitoring sites.

A secure element does not protect against every possible attack. If the running firmware is completely compromised, an attacker may still be able to request signing or cryptographic operations from the SE050.

Its main security benefit is therefore to make private-key extraction and cloning much more difficult.

Ethernet OTA

The W5500 is used not only for Reticulum traffic, but also for device maintenance.

W5500 Ethernet
 ├─ Reticulum TCP Backhaul
 ├─ Configuration
 ├─ NTP
 └─ Firmware OTA

New firmware can be uploaded over Ethernet.

The device then performs a trial boot. If the new firmware does not pass the expected validation process, the system can roll back to the previous firmware image.

This is especially useful for remote gateways because firmware updates and recovery can be performed without physically connecting a USB cable.

Performance Results

An unattended test was performed for approximately 167.9 hours.

No resets occurred during the test.

The missed probes on the LoRa path were correlated with periods when the SX1262 was transmitting and therefore unable to receive because the LoRa radio operates in half-duplex mode.

This highlights the different roles of the two interfaces:

• Ethernet: Stable, continuous backbone connectivity
• LoRa: Lower-bandwidth but long-range wireless edge connectivity

Applications

This architecture can be used in a wide range of applications.

With the WIZPoE-P1, a rooftop or remote gateway can also receive both network connectivity and power through a single Ethernet cable.

Comparison with Existing WIZnet Maker Projects

The hardware concept is similar to the existing Pico2 + W5500 + E22 project, but this project develops the concept into a fully operating network infrastructure node.

W5500 + RP2350 + E22
          ↓
    microReticulum
          ↓
 Ethernet ↔ LoRa Routing
          ↓
 OTA + Secure Identity
          ↓
 Long-term Stability Test

Conclusion

The architecture of this project can be summarized in one sentence:

LoRa provides the long-range wireless edge, W5500 provides the reliable Ethernet backbone, and Reticulum connects both communication domains into one network.

By combining this architecture with SE050-protected X25519 and Ed25519 identity keys, Ethernet OTA, rollback support, and long-term stability testing, the project demonstrates how a compact RP2350-based device can operate as a practical standalone Reticulum Transport Node for remote and infrastructure-limited environments.