Fix RAK4631 Ethernet gateway API connection loss after W5100S brownout

[PhilipLykov]

Summary

RAK4631 Ethernet gateway devices (RAK13800-W5100S) lose API connectivity after a few minutes of operation while radio and ping continue to work. Only a power reset recovers connectivity.

Root cause: PoE power instability can brownout the W5100S Ethernet chip while the nRF52 MCU keeps running. This causes all W5100S registers (MAC address, IP configuration, socket states) to silently revert to defaults. The firmware had no mechanism to detect or recover from this hardware-level reset. Several pre-existing software issues compounded the problem by preventing graceful recovery even from normal TCP disconnects.

Changes

1. W5100S reset detection and recovery (ethClient.cpp): Periodically verify the W5100S MAC address register in reconnectETH(). On mismatch (indicating a chip reset), perform a full hardware reset via PIN_ETHERNET_RESET, re-initialize the Ethernet interface (MAC, IP via DHCP/static), and trigger re-initialization of all Ethernet services (API server, NTP, syslog, UDP multicast) by resetting the ethStartupComplete flag.

2. API server clean teardown (ethServerAPI.cpp/.h): Add deInitApiServer() function (matching the existing WiFi convention) to properly destroy the API server during Ethernet re-initialization, preventing stale socket/pointer issues.

3. UDP multicast teardown on brownout recovery (ethClient.cpp): Stop the UDP multicast handler (udpHandler->stop()) during W5100S reset recovery. Without this, the handler's isRunning flag stays true after a chip brownout, causing start() to no-op during re-initialization and leaving multicast silently broken after recovery.

4. Switch nRF52 to accept() (ServerAPI.cpp): Change nRF52 from EthernetServer::available() to accept() (aligning with RP2040). available() repeatedly returns the same connected client, causing the server to attempt re-accepting an already-active connection.

5. Proactive dead-connection cleanup (ServerAPI.cpp): Check and clean up disconnected openAPI instances at the beginning of APIServerPort::runOnce() before accepting new connections.

6. TCP idle timeout (ServerAPI.cpp): Add a 15-minute inactivity timeout to forcefully close half-open TCP connections. The W5100S has only 4 hardware sockets, and half-open connections from crashed clients permanently consume them.

Note: The original PR also added an ~APIServerPort() destructor to delete openAPI, but this is no longer needed — upstream develop changed openAPI from a raw pointer to std::unique_ptr, which handles cleanup automatically.

Hardware context

• W5100S has a strict limit of 4 hardware sockets
• W5100S lacks hardware TCP keepalive
• PoE-powered devices are susceptible to voltage transients that can brownout the W5100S while the MCU continues running
• Symptom observable on the network switch: multiple random MAC addresses appearing on the port where only one device is connected

Fixes #6970

Test plan

• Build rak4631_eth_gw target successfully
• Deploy to RAK4631 + RAK13800 device with PoE
• Verify API connectivity persists beyond the previous failure window (typically a few minutes)
• Verify radio functionality is unaffected
• Monitor switch port for MAC address stability (should see only one consistent MAC)
• Verify DHCP lease renewal works after recovery
• Test with static IP configuration
• Verify NTP re-synchronization after recovery
• Confirm no regressions on ESP32 and RP2040 Ethernet targets

[Xaositek]

@PhilipLykov You think this would resolve this issue? #8462

[Copilot]

Pull request overview

This PR fixes a critical issue where RAK4631 Ethernet gateway devices lose API connectivity after a few minutes due to W5100S chip brownouts caused by PoE power instability. The fix implements hardware reset detection, proper recovery mechanisms, and several improvements to TCP connection management to prevent socket exhaustion.

Changes:

• Added W5100S chip reset detection by monitoring MAC address registers and full re-initialization on mismatch
• Implemented proper API server teardown (deInitApiServer()) and destructor to prevent memory leaks during recovery
• Fixed nRF52 connection handling to use accept() instead of available() and added proactive cleanup of dead connections
• Added 15-minute TCP idle timeout to prevent half-open connections from exhausting the W5100S's 4 hardware sockets

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
src/mesh/eth/ethClient.cpp	Implements W5100S reset detection via MAC verification and full hardware re-initialization
src/mesh/api/ethServerAPI.h	Adds deInitApiServer() declaration for clean API server teardown
src/mesh/api/ethServerAPI.cpp	Implements deInitApiServer() to properly destroy the API server
src/mesh/api/ServerAPI.h	Adds destructor to prevent memory leaks and isClientConnected() helper method
src/mesh/api/ServerAPI.cpp	Implements TCP idle timeout, proactive dead-connection cleanup, and switches nRF52 to accept()

[PhilipLykov]

@PhilipLykov You think this would resolve this issue? #8462
There is mixed the issue with -7 in radio with issue with the Ethernet. But I believe my PR will fix the issue with Ethernet described there.

[PhilipLykov]

Re: #8462 - This PR does not fix that issue. #8462 is a different bug on the radio side (RadioLib error -7 = RADIOLIB_ERR_CRC_MISMATCH), where the SX1262 LoRa radio stops decoding packets correctly after a few days.

The two chips live on completely separate SPI buses on the RAK4631:

• SX1262 (LoRa radio): SPI main bus (pins 42-45)
• W5100S (Ethernet): SPI1 secondary bus (pins 3, 29, 30, 26)

This PR fixes W5100S Ethernet chip brownout recovery (API/TCP connectivity loss). The radio CRC issue in #8462 would need its own detection and recovery - likely periodic verification of SX1262 configuration registers and re-initialization if corrupted.

However, if both issues are triggered by the same PoE voltage transients, the root cause is the same (power instability), just affecting different chips independently.

[PhilipLykov]

@robekl Good observation — this is intentional and consistent with how the rest of the Meshtastic codebase handles connection timeouts.

lastContactMsec is only updated on inbound data by design. Both SerialConsole and SerialModule use the exact same pattern — a 15-minute timeout based solely on inbound lastContactMsec (see SERIAL_CONNECTION_TIMEOUT in SerialConsole.cpp:27 and SerialModule.cpp:61). Our TCP timeout mirrors this existing convention.

Why not update on outbound traffic? The purpose of this timeout is to detect dead/abandoned connections (crashed clients leaving half-open TCP sockets). If we updated lastContactMsec on outbound data, a node that keeps forwarding mesh packets to a dead client would keep the connection alive forever — exactly the socket leak we need to prevent. The W5100S has only 4 hardware sockets; we cannot afford that.

The Meshtastic protocol already accounts for this via the heartbeat message (meshtastic_ToRadio_heartbeat_tag). Clients are expected to send periodic heartbeats, and each heartbeat flows through handleToRadio() which updates lastContactMsec. The official Meshtastic app sends these regularly, so compliant clients will never hit the 15-minute window.

[Xaositek]

@PhilipLykov Can you address the merge conflicts on this one?

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

---

You can also share your feedback on Copilot code review. Take the survey.

[Xaositek]

@PhilipLykov Sorry to bug you again but please review the CoPilot suggestions and determine if we want to add them or not. Thanks!

[PhilipLykov]

@Xaositek Thanks for the nudge! Reviewed both Copilot suggestions:

1. UDP multicast not torn down during brownout recovery (ethClient.cpp) — Good catch by Copilot. After a W5100S brownout, the udpHandler->isRunning flag stays true while the underlying socket is dead, so start() would silently no-op on recovery. Fixed in 41d0757 — added udpHandler->stop() in the teardown path alongside syslog.disable() and deInitApiServer().

2. PR description mentions destructor that no longer exists (ServerAPI.cpp) — Correct observation. The original PR added ~APIServerPort() { delete openAPI; } when openAPI was a raw pointer, but upstream develop changed it to std::unique_ptr, making the manual destructor unnecessary. It was correctly removed during the merge conflict resolution. Updated the PR description to reflect the current state.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 5 comments.

---

You can also share your feedback on Copilot code review. Take the survey.

[PhilipLykov]

Addressed the latest Copilot review — all fixes pushed in d396b0a:

1. ethStartupComplete not reset on early return — Good catch. If Ethernet.begin() failed (e.g. DHCP timeout), the early return left ethStartupComplete = true. Since DHCP writes the MAC even on failure, the next iteration would see a matching MAC, skip the recovery block, and skip the startup block — leaving all services permanently dead. Fixed by moving ethStartupComplete = false and ntp_renew = 0 to immediately after service teardown, before Ethernet.begin().

2. Unsafe deletion of apiPort — This is a false positive in context. Meshtastic uses cooperative single-threaded scheduling (concurrency::OSThread). reconnectETH() and apiPort->runOnce() execute in the same event loop — no concurrent access is possible. No mutex or shutdown sequence needed.

3. #define → static constexpr — Agreed, replaced #define TCP_IDLE_TIMEOUT_MS with static constexpr uint32_t for type safety.