RAK10720 gateway loses Ethernet access, recovers after Bluetooth or reboot

A RAK10720 gateway that still seems alive on the mesh can quietly fall off the wire: the node stops answering on its IP address, disappears from the map, and only comes back after someone connects over Bluetooth or reboots it. The report, opened on April 29, 2026, identifies a RAK WisBlock 4631 running firmware 2.7.15.567b8ea in EU_868 with LongFast, seven hops, frequency slot 1, and power configuration set to off.

That matters because this is not just a convenience glitch. For a gateway sitting on Ethernet or PoE, losing IP reachability means losing network visibility, management access, and trust in the box as fixed infrastructure. The mesh side can still look healthy while the IP side is gone, which makes the failure easy to miss until the gateway is needed most. The pattern also points to a specific kind of problem: something in the interaction between Ethernet, runtime state, and the code path that BLE or reboot reinitializes.

Meshtastic’s own network configuration notes make the stakes clearer. Ethernet is a supported option, but only one connection method works at a time. The same documentation says enabling Wi-Fi disables Bluetooth, and the first restart after enabling Wi-Fi or Ethernet can take an extra 20 to 30 seconds because the device generates self-signed SSL keys. In other words, network services and local management are tightly linked, so a fault that touches one path can spill into the others.

The hardware context makes the report especially relevant for always-on deployments. The RAK WisMesh Ethernet MQTT Gateway is built around a RAK19007 base board, a RAK4631 nRF52840 core, BLE 5.0, and an SX1262 LoRa transceiver. It is described as a stable wired bridge to MQTT brokers, requires an external power source, and can use a PoE module, which puts it squarely in the infrastructure category rather than the casual-node bucket.

There is also recent history behind the symptom. Meshtastic firmware 2.7.21 included fixes for RAK4631 Ethernet gateway API connection loss after W5100S brownouts and for W5100S socket exhaustion that blocked MQTT and additional TCP clients. Earlier GitHub reports also described a RAK4631 Ethernet MQTT gateway that could not open the webserver and only exposed port 4403, as well as missing Bluetooth on the RAK WisMesh Ethernet MQTT Gateway in 2.7.3 and 2.7.4 even though Bluetooth had worked on 2.5.x and 2.6.x. For operators, the takeaway is blunt: watch Ethernet reachability, map presence, and recovery behavior, not just RF traffic, because a gateway that still hears the mesh can still fail the network that is supposed to keep it visible.