lfg2025/archy
1
0
Fork 0
Code Issues 20 Pull Requests Actions Packages Projects Releases 61 Wiki Activity
archy/docs/HANDOFF-2026-07-23-companion-apk-deploy.md
Dorian 53037b2b71 fix(companion): TUN reader no longer dies on non-blocking fd + VPN not metered 
On-device diagnosis (phone on adb, 5G): mesh sessions established but no
packet ever entered the tunnel — Android hands the VpnService TUN fd over
non-blocking, and the fips fork's dedicated blocking-read thread treats
EAGAIN as fatal, dying at startup. archy-fips-core now forces the fd into
blocking mode before Node::start_with_tun_fd. Verified on-device: reader
survives, packets flow into the mesh, and the 30s anchor-link flap is
gone (stable 8+ min on 5G).

Also setMetered(false): Android 10+ defaults VPNs to metered, flipping
the phone into data-restricted behaviour whenever the mesh is up.

Served APK: 0.5.4 (vc24). Handoff updated with the remaining node-side
blocker: phone->anchor works, phone->node ULA gets no reply — needs
fipsctl introspection on Framework PT (suspect fork/daemon session or
routing mismatch).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-23 22:47:26 +01:00

5.2 KiB
Raw Blame History

HANDOFF — deploy companion APK 0.5.1 (vc21) to nodes

For: the agent on archi-dev-box. User-reported failure this evening: pairing flow on Framework PT — downloaded the companion from the node's QR, then the pairing scan didn't work. The APK the node serves predates today's scanner fixes; the pipeline below gets the fixed build into the user's hands.

What changed on main today (all merged)

  • Pairing-scanner fix (QrScannerOverlay.kt): ZXing decode attempts are frame-gated (~7/s, was every frame — the CPU contention made the preview stutter badly enough to never decode) and PreviewView uses TextureView (no more black flash on open). This is the likely fix for "doesn't scan".
  • Three-finger menu gesture (was two-finger, collided with scroll) + one-time teaching overlay ~2 min after login.
  • Native wallet QR scanner behind window.ArchipelagoQr + WebView file-chooser support; web scan modal hands live scanning to it.
  • npub-keyed saved servers (pairing contract item 1, PR #106).
  • Served APK refreshed: neode-ui/public/packages/archipelago-companion.apk is now 0.5.3 / versionCode 23. On top of the 0.5.1 scanner fixes it guarantees dual-path peering — the node's LAN endpoint (direct p2p, npub- keyed dial hints) AND the Archipelago public anchor (vps2, baked into the app so even an old node's QR can't leave the phone LAN-only) — and fixes the two field failures from the user's 5G test (screenshots, 21:54):
    • Mesh VPN no longer kills the phone's internet — the IPv6-only TUN never called allowFamily(AF_INET), so Android blocked all IPv4 while the mesh was up. Now allowed (+ allowBypass).
    • Off-LAN connect works — connect() no longer hard-fails when the scanned LAN IP doesn't answer; it brings the mesh up and probes the node's ULA (meshIp) with retries before reporting failure.

What to do

  1. Redeploy the web-ui bundle from current main to the active nodes — web root /opt/archipelago/web-ui/ (NOT a neode-ui/ subfolder), all nodes the user pairs against, at minimum the one Framework PT scans.
  2. Verify the served artifact really updated: curl -sI http://<node>/packages/archipelago-companion.apk — size should change (~27 MB build of 2026-07-23), or pull it and check aapt dump badging shows versionCode='21' versionName='0.5.1'.
  3. The demo stack gets its images from CI (run 100 pushed today with the new web bundle) — confirm the Portainer stack re-pulled, or trigger its redeploy, so the demo QR also serves vc21.
  4. Node side is half the 5G story: away-from-home reachability needs the NODE connected to the public anchor too. On Framework PT (and any test node): deploy current main (node-side npub-first fips.pair-info), then verify sudo -n fipsctl show status reports the anchor connected — fips.reconnect RPC if not. A phone can dial the anchor perfectly and still fail if the node never enrolled with it.
  5. Re-test the user's exact flows with vc24 (updates any older install in place): (a) pair ON the LAN, then switch the phone to 5G — the UI must come up via the mesh ULA; (b) pair while ALREADY on 5G (never on the node's LAN) — scan, VPN consent, and the connect must succeed through the anchor.

Live diagnosis update (22:30–22:50, phone on adb — Mac agent)

vc23 on-device testing found and fixed the phone-side blocker, and narrowed what remains to the node side. State as of vc24:

  • Fixed: TUN reader died at startup. Android hands the VpnService fd over non-blocking; the fips fork's blocking reader thread treats EAGAIN as fatal ("TUN read error … Try again (os error 11)") — so mesh sessions came up but NO packet ever entered the tunnel. archy-fips-core now forces the fd blocking before start_with_tun_fd. Verified on-device: reader survives, and the 30s anchor-link flap disappeared with it (stable 8+ min on 5G).
  • Fixed: VPN marked not-metered (setMetered(false)) — Android 10+ defaults VPNs to metered, putting the phone into data-restricted behaviour while the mesh is up. Note the user's phone also has system always-on VPN enabled for the app (always_on_vpn_app), a Settings-side toggle.
  • Verified good on-device: peer store has node (LAN udp/tcp hints) + vps2 anchor; saved server is npub-keyed with ULA; anchor session establishes from 5G in ~6s; VPN is bypassable, VALIDATED, only fd00::/8 routed.
  • REMAINING BLOCKER (node side): from the phone (app uid), ping6 and HTTP to the node's ULA fd79:1aa:b9e9:4c9f:1f80:5376:9385:1824 get no reply — packets enter the mesh, nothing returns. Phone↔anchor works, so suspect phone-fork ↔ node-daemon session/routing mismatch (FIPS wire format is not stable across revs; phone pins fips-native fork 46494a74). From Framework PT please capture:
    • fipsctl show status (daemon version + anchor state)
    • fipsctl show sessions and show bloom while the phone pings
    • ping6 <phone ULA fd68:496d:fe34:a06d:cf1:6e4:b6a4:3586> from the node (tests the reverse path)
    • ip addr show fips0 + confirm the web server listens on [::]:80 Report whether the node ever sees a session attempt from npub132c5whrsa6ccs0eylcpzaejq9uxul5ldvczz0axq78dh7fxkqj9st4uvzu.