René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"net: intelligent backhaul selection, then optional selective sharing","articleBody":"## Why\n\nv0.11.3 shares backhaul probabilistically: new connections are split across all uplinks using speed-test results. This has proved unreliable:\n- **Small tests:** the tests have to be small to limit mobile data use, especially for international partners.\n- **Bad startup results:** tests run while interfaces are still coming up can be badly wrong, and the resulting weights can persist for hours.\n\n#357 replaces this with fixed-priority failover (wired WAN, then modem 1, then modem 2), which a custom build has already shown to be more stable. But a fixed order ignores quality. For example, it will prefer an Ethernet uplink from a slow LTE router over a much faster internal 5G modem.\n\nThis issue tracks replacing fixed priorities with informed selection, and later reintroducing sharing only where it helps.\n\n## Stages\n\n### 1. Validate failure recovery on v0.12\nWith backhaul sharing, connections assigned to a modem could stay stuck after that modem reset, even with another working backhaul available. A possibly related fix is in v0.12 (#350, the cellular interface restart on reconnect).\n- Run sustained multi-connection downloads across the available backhauls.\n- Reset or disconnect a modem mid-transfer.\n- Record whether existing connections recover, reconnect or stay stuck, and how long new connections take to use a healthy backhaul.\n- Compare v0.11.3 and v0.12.\n- If connections still stick, look at conntrack/routing state for failed interfaces (selective cleanup). Sessions can't migrate between public IPs, so the aim is fast, reliable reconnection.\n\n### 2. Backhaul assessment\n- **Cellular** (no data cost):\n  - modem capability (LTE category, 5G, carrier aggregation);\n  - radio technology, band, bandwidth, CA;\n  - SNR / RSRQ / RSRP;\n  - latency and packet loss.\n\n  First check which of these are consistently available across the EG25-G, EM12-G and RM520N-GL.\n- **Ethernet:**\n  - lightweight connectivity/latency/loss monitoring;\n  - passive observation of real throughput;\n  - small threshold tests against self-hosted endpoints (controlled size and frequency, for Ethernet that is itself on metered cellular);\n  - public IP / ASN / gateway identification as context.\n- Each backhaul gets a health status, an estimated capacity or suitability score, and a **confidence**. A short Ethernet test can under-read, and a radio-based cellular estimate can over-read under congestion.\n- Validate the estimates against measured throughput.\n\n### 3. Intelligent failover\n- Select the most suitable available backhaul from estimated capacity, connectivity, latency/loss, confidence, data cost and configured preferences.\n- Never delay basic connectivity. At startup, or while estimates are unreliable, use the conservative default order from #357.\n- Filter radio measurements (median, then EWMA). Reassess on cell change. One poor startup measurement must not mark a link slow for long.\n- Switching:\n  - fast failover on failure;\n  - switch on significant, sustained degradation;\n  - stay put on a marginal improvement elsewhere;\n  - consider switching only on a substantial, sustained improvement (switching breaks existing TCP sessions).\n\n### 4. Validate\nCompare against the fixed-priority build and v0.11.3 sharing. Cover different radio conditions, Ethernet backhaul types, congestion and moving-vehicle installs. Measure reliability, user experience, selection choices and recovery time.\n\n### 5. Optional selective sharing\n- Share only between Ethernet and the best modem; the second modem stays on standby.\n- Share only when both links are capable enough and the extra capacity is worth it. Starting point to validate: both ≥ 10 Mbps, and the slower ≥ 25% of the faster. Also consider latency/loss, confidence, current demand and data cost.\n- Allocate new connections in proportion to estimated capacity from radio estimates, limited Ethernet tests and passive observation, not from small cellular speed tests.\n- A backhaul that falls below the threshold stops getting new connections; existing ones finish where they are.\n\n## Related\n- #357: strict failover, the baseline for this work.\n- #302: choppy connectivity mixing a fast WAN with a weak SIM.\n- #348: speed-test accuracy.\n- #356: mwan3 restarting uplinks offline.\n- #350: cellular interface restart on reconnect.\n","author":{"url":"https://github.com/cpunt","@type":"Person","name":"cpunt"},"datePublished":"2026-11-02T16:36:03Z","url":"https://github.com/jangala-dev/devicecode-lua/issues/360"}