From ee9ca0b5beb0e47b6375fcbb732c18da9429ca3d Mon Sep 17 00:00:00 2001 From: Elias Bakken Date: Sun, 9 Aug 2026 21:26:23 +0200 Subject: [PATCH] Bump WiFi client connect timeout from 30s to 60s Observed a real timeout on a 5GHz network in practice: the boot-time connection attempt hit the full 30s window and fell back to hotspot, even though the network was reachable and reconnecting manually succeeded moments later. 5GHz scanning (particularly across DFS channels, which require slower passive scanning) can plausibly eat into a cold boot-time connect more than 30s comfortably allows. The cost is asymmetric: a longer timeout just means a slightly longer boot delay in the rare case the SSID truly isn't reachable, but a too -short timeout means falling back to hotspot even when the network would have connected given a few more seconds - which then needs manual intervention to fix, defeating the point of #65's design (hotspot is meant to be a last-resort backup, not something to hit routinely). Co-Authored-By: Claude Sonnet 5 --- userpatches/overlay/autohotspot/autohotspot | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/userpatches/overlay/autohotspot/autohotspot b/userpatches/overlay/autohotspot/autohotspot index 3a33a71..21c9cc4 100644 --- a/userpatches/overlay/autohotspot/autohotspot +++ b/userpatches/overlay/autohotspot/autohotspot @@ -10,7 +10,7 @@ hotspot_PW="12345678" # How long to wait for the configured network at boot before falling # back to the hotspot. Only boot-time availability matters here - if # the connection later drops, we deliberately do not fall back. -CLIENT_TIMEOUT=30 +CLIENT_TIMEOUT=60 create_hotspot() { echo "Creating hotspot"