meshtastic-rak3312-ethernet

How Does a Community Patch Bring W5100S Ethernet and PoE to the RAK3312 Meshtastic Gateway?

Summary — RAKwireless sells Meshtastic gateway kits with a RAK13800 Ethernet module (WIZnet W5100S) and a PoE module, but on the ESP32-S3-based RAK3312 core the official firmware never turned Ethernet on. This community patch makes it work: DHCP, the Meshtastic TCP API, NTP and syslog run over the W5100S, Wi-Fi and Ethernet run side by side, and the gateway runs from a single PoE cable.

At a Glance

What Problem Does It Solve?

Meshtastic is open-source firmware that turns small LoRa radios into a text-messaging mesh network that works without phones or cellular coverage. Nodes relay messages for each other, which makes it useful in mountains, disaster zones and large events. To connect the mesh to a server, an app or the internet, you need a gateway node — and a gateway is usually installed somewhere high, where both power and a network connection have to be brought to it.

RAKwireless sells WisBlock-based Meshtastic gateway kits for exactly this job. The kits include the RAK13800 Ethernet module (W5100S-L) and the RAK19018 PoE module. However, in the official Meshtastic firmware the author checked, the rak3312 (ESP32-S3) board target had no Ethernet pin definitions at all. Setting network.eth_enabled did nothing and reported no error.

meshtastic-rak3312-ethernet fills that gap. It is a patch against Meshtastic develop plus prebuilt binaries, and a long README that explains every change and every failure the author hit on the way.

In one line: the patch turns a W5100S gateway kit that is already sold into a real wired, PoE-powered Meshtastic gateway — and documents the traps that kept it from working.

Key Technical Features

1. A separate SPI bus for the W5100S

The LoRa radio already initializes the global SPI object on GPIO 5/3/6/7 at boot. On Arduino-ESP32, a second SPIClass::begin() call with different pins is silently ignored, so the W5100S was effectively wired to the LoRa pins — the result was DHCP timeouts and "Ethernet shield was not found". The patch gives the W5100S its own HSPI peripheral (SPIClass EthSPI(HSPI)) on GPIO 13/10/11/12. This is the single most important finding of the project, and it applies to any ESP32 board that combines a radio and a WIZnet chip on separate pins.

2. Wi-Fi and Ethernet together

Every Ethernet board Meshtastic supported before was Ethernet-only, so Wi-Fi and Ethernet code had never been compiled into the same image. Doing so caused "multiple definition" link errors (syslog, timeClient, initApiServer()…). The patch renames only the Ethernet side (ethSyslog, initEthSocketApiServer(), …). It also fixes a second problem: both interfaces used the ESP32's Wi-Fi STA MAC, which made Ethernet unreachable once Wi-Fi came up. Ethernet now uses its own address from esp_read_mac(…, ESP_MAC_ETH).

3. Running on PoE alone — and surviving PoE sag

The gateway was verified on PoE power only (no USB), answering 180/180 pings over several minutes. Under load, the RAK19018 supply can sag enough to reset only the W5100S while the ESP32 keeps running. The RAK13800 library detects this ("W5100S MAC mismatch (chip reset detected)"), and the patched code shuts down syslog and the API server and re-initializes Ethernet.

4. Using hardware sockets carefully

The W5100S has a small, fixed number of hardware sockets. After each NTP sync, the patch calls ethTimeClient.end() to release the UDP socket for other services (code comment: "W5100S: release UDP socket for other services"). NTP is refreshed hourly and retried after 5 minutes on failure.

5. Built to be merged upstream

Instead of modifying the stock rak3312 target, the patch adds a separate build environment, rak3312_eth_gw — the same approach as the official rak4631_eth_gw. The RAK13800 library is bumped from 1.0.2 to 1.0.4. The change was filed as issue #12190 (2026-10-18) and PR #12232 (2026-10-24).

How Is Ethernet Used?

On this node the LoRa radio faces the mesh and the W5100S faces the wired LAN. Everything that leaves the gateway over IP runs on W5100S hardware sockets:

What the TOE does here

The ESP32-S3 is busy driving the SX1262 radio, relaying mesh packets, managing the node database and handling Bluetooth and Wi-Fi. The W5100S runs the TCP/IP stack for the Ethernet side inside the chip, so the firmware only opens, reads and writes sockets through the RAK13800 library's Ethernet.h / EthernetServer / EthernetUDP API.

Why wired instead of Wi-Fi?

Where Does It Fit in the Market?

A product that is already sold

This is not a one-off maker build. The hardware is RAKwireless's WisBlock gateway combination — RAK3312 core, RAK13800 (W5100S), RAK19018 PoE and a base board — and the W5100S ships inside every RAK13800. Meshtastic already supports the same module on the nRF52840 (rak4631_eth_gw) and RP2040 (rak11310) targets; this patch extends it to the ESP32-S3 core. Once the PR is reviewed, every RAK3312 gateway built with a RAK13800 gets working wired Ethernet.

Who uses a wired Meshtastic gateway

These fields describe how this gateway pattern is typically applied; the project itself documents a single test unit.

What it shows for WIZnet

• Ecosystem support: a popular open-source project gaining W5100S support on a new MCU family, through a public PR.
• "Wireless mesh + wired PoE gateway" is a repeatable product pattern — LoRa, Thread or BLE endpoints on batteries, one wired gateway on PoE.
• Integration lessons that matter to anyone pairing a radio and a WIZnet chip on an ESP32: separate SPI peripherals, a dedicated Ethernet MAC, and socket budgeting.

System Architecture

[LoRa mesh nodes — Meshtastic devices]
        |  LoRa (SX1262, inside RAK3312)
[RAK3312 — ESP32-S3: mesh routing · NodeDB · config]
        |  SPI #1  LoRa only        (GPIO 5/3/6/7)
        |  SPI #2  EthSPI / HSPI    (GPIO 13/10/11/12)
[RAK13800 — WIZnet W5100S-L: DHCP · TCP 4403 · UDP (NTP / syslog)]
        |  RJ45  <-- RAK19018 PoE (power)
[Wired LAN — router · Meshtastic app / CLI · MeshMonitor · syslog · NTP]

   (in parallel) ESP32-S3 Wi-Fi — optional, runs alongside Ethernet from v2.0.0

Hardware and Pins

• The RAK13800 is powered from the IO-slot rail, which the stock rak3312 definition already enables (GPIO14, PIN_3V3_EN).
• With a RAK4631 (nRF52840) core this patch is not needed — the official rak4631_eth_gw target already supports the RAK13800.
• Install: after a full erase, write factory.bin at 0x0; for updates, write app-only.bin at 0x10000. To build: apply the patch to commit 95ff510 (2.8.2.326ccb2) and run pio run -e rak3312_eth_gw.

Known Limits

• Static IP does not work yet — settings are saved but the device comes up as 0.0.0.0. Use a DHCP reservation on the router.
• TCP writes can be lost on nodes with a large NodeDB — on a device holding 70+ nodes, the CLI disconnects before the history replay finishes. The author recommends USB for configuration writes and TCP for reading and monitoring.
• Flash is nearly full — 2,302,551 of 2,424,832 bytes (about 95%).
• Tested on one unit — long-term uptime and multi-unit tests have not been done (stated by the author).

FAQ

Q. Did the author choose the W5100S?
No. The RAK13800 in RAKwireless's gateway kits uses the W5100S-L, and Meshtastic's official rak4631_eth_gw and rak11310 targets already use the same module and library. The patch extends that proven combination to the ESP32-S3 core.

Q. Why can't the W5100S share the LoRa SPI bus?
On the ESP32-S3, calling begin() again on an initialized SPI object with different pins does nothing. The W5100S needs its own HSPI peripheral. When porting to another ESP32 board, check the boot log for two separate SPI initializations.

Q. Is it part of official Meshtastic?
Not yet. PR #12232 is open and awaiting review as of 2026-11-09, and the author describes it as an unofficial patch.

Q. Can Wi-Fi and Ethernet run together?
Yes, from v2.0.0. Ethernet uses its own MAC (ESP_MAC_ETH), and syslog is sent over both interfaces.