From 45773f745919009db0c98eddf32dcfde06f2094b Mon Sep 17 00:00:00 2001 From: Mathieu Moran Date: Sun, 9 Aug 2026 15:56:17 -0400 Subject: [PATCH] Document phone-relay hotspot+cellular test findings in PLAN.md Live-tested the away-from-home hotspot+cellular relay scenario. Found the netwatch reconnect bug (documented in Phase 6 update) during this test. Confirmed the relay architecture itself needs no code changes - the TypeError: Failed to fetch was a phone-OS network-switching behavior (won't route internet traffic over cellular while connected to a no-internet WiFi), not a CORS/code issue - ruled out via a plain page navigation test. Testing this fully requires being genuinely away from home or manually forcing cellular use on the phone. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --- PLAN.md | 44 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 44 insertions(+) diff --git a/PLAN.md b/PLAN.md index 16b9638..1009589 100644 --- a/PLAN.md +++ b/PLAN.md @@ -236,6 +236,20 @@ is a no-op when already on home WiFi); `http://yaris.local/` and `http://home reconnect was flaky)**: while testing +the phone-relay feature live (see Phase 9 update below), `yaris-netwatch` repeatedly logged "home +WiFi not found" 4 times in a row over ~13 minutes while sitting right next to the router — a real +regression from the original design, not a one-off fluke. Root cause: a plain `nmcli con up +home-wifi` straight out of AP mode relies on NM's scan cache for `wlan0`, which is stale/empty +coming out of AP mode (the radio can't scan while acting as an AP - see above). A single +`--wait 20` connect attempt gave up before a fresh scan could land. Fixed `yaris-netwatch.sh` to +explicitly drop the AP connection first (releases the radio), force `nmcli device wifi rescan`, +wait for it to settle, then retry the connect (longer 30s wait) up to 2 times before conceding and +restoring the hotspot. Bumped `yaris-netwatch.service`'s `TimeoutStartSec` to 180s (retry loop can +take up to ~80s, default systemd 90s start timeout was too tight). Verified fixed on real hardware: +both hotspot->home transitions after the fix recovered in ~7 seconds (previously failing outright). +Deployed: `sudo cp deploy/yaris-netwatch.sh /usr/local/bin/... && cp .service ... && daemon-reload`. + ### Phase 7: app_db.py / app_sql.py fixes — DONE Neither file was called from `app.py` or anywhere else - orphaned from a prior iteration. Fixed: - `app_db.py`: applied a prior-session stash fix - resolves `.env` path via `__file__` (was @@ -565,6 +579,36 @@ the phone and select specific ones to view or upload (as opposed to bulk-relayin backlog) — useful for "just grab this one important clip" rather than a wholesale speed optimization. Not scoped/designed yet. +**Update — tested the "away from home" hotspot+cellular scenario for real, found a real phone-OS +limitation (not a code bug)**: the user asked to test the specific scenario the relay feature was +actually designed for — phone connects to the **Pi's own hotspot** (not home WiFi) to download +pending files, then re-uploads using the phone's **cellular data**, bypassing the Pi's own (in +hotspot mode, nonexistent) internet connection entirely. Confirmed via code review this needs zero +changes: `/api/dash/relay/config` already hands the phone the public `https://yaris.ceaf.dev` +`SERVER_URL` (not a LAN-only address), so the re-upload leg was always going to be internet-bound +regardless of which physical network carries it. + +Live-tested with a real dummy file (dashcam upload toggle paused first so the Pi's own uploader +couldn't grab it before the phone did): got `TypeError: Failed to fetch` trying to relay. Confirmed +via a direct test (loading `https://yaris.ceaf.dev/health` as a plain page navigation, not a +`fetch()`, ruling out CORS) that **the phone's own OS was declining to route internet-bound traffic +over cellular while still associated with the Pi's no-internet-gateway hotspot WiFi** — it only +succeeded once the phone auto-fell-back to the home WiFi network (which does have internet) +instead. This is a phone/OS-level "smart network switching" behavior (common on both iOS and +Android to avoid using a WiFi network with no internet gateway) that cannot be fixed in this +project's code — the architecture is sound and was already proven correct in the local end-to-end +simulation and the byte-for-byte reassembly tests earlier in this phase. + +**Practical implication**: testing this exact scenario **at home is inherently confounded** — the +phone always has a known-good home WiFi it can silently fall back to, defeating the test. A true +validation needs either (a) actually being away from home with no known WiFi in range, forcing the +phone to use cellular for internet traffic, or (b) manually disabling the phone's WiFi (or its +"switch to mobile data automatically" setting) while connected to the Pi's hotspot, to force +cellular use for this one operation. Not yet re-tested under either condition. + +**Side-fix from this test session**: found and fixed a real, unrelated bug in `yaris-netwatch.sh` +during this same test — see the Phase 6 update above. + ## Working Notes / Environment Gotchas - **Pi credentials/SSH**: `ssh yaris@`. Confirm current IP before connecting (varies by