docs(openwrt): document the confirmed working end-to-end install flow

Adds a verification checklist (service running, nodogsplash bound to br-tollgate not br-lan via the rendered config not just UCI, LAN/SSH untouched, mint probes succeeding) plus notes on the dev-build test-mint injection and the default-route race between a router's LAN interface and the node's other uplinks before the router's own WAN/WISP is live. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0176RpCxFNS9ZaSJjL72W9Z5
docs(openwrt): note the Ctrl+T/LuCI workaround for setting the initial root password
2026-09-07 03:06:58 +00:00 · 2026-09-07 02:53:21 +00:00 · 2026-09-05 17:28:20 +00:00 · 2026-09-05 16:36:53 +00:00 · 2026-09-05 15:14:07 +00:00 · 2026-09-05 15:14:00 +00:00
22 changed files with 992 additions and 136 deletions
@@ -1,5 +1,13 @@
 # Changelog

+## v1.8.10-alpha (2026-09-02)
+
+- **Lightning sends work again — v1.8.9's payment switch lost the fee budget.** Moving payments to LND 0.21's supported route (Router.SendPaymentV2) shipped without a fee limit, and the v2 API treats an absent limit as **zero allowed fees**: every real route carries a routing fee, so the pathfinder rejected them all and the wallet answered "No route to the recipient" on every send — all day, on healthy channels with plenty of liquidity. The router debug log made it unambiguous (`fee_limit=0 mSAT` on every failing wallet payment; the same payment succeeded by hand the moment a fee limit was set). Payments now carry lncli's default budget (the payment amount), the wallet's amount handling for zero-value invoices is preserved, and a unit test pins the limit can never be zero again.
+
+- **A channel that drops its peer link now heals itself — on every node.** Restarting LND (an app update, a reboot, container churn) can leave a channel's peer connection down for hours while both endpoints keep the channel flagged disabled in the routing graph: the node looks perfectly healthy, the wallet shows balance, and every payment in either direction fails "no route to the recipient". Observed live: a node's only channel sat unroutable for ~17 hours after the LND 0.21.2 update, with no sign of it in any dashboard. The daemon now watches the channel graph as desired state — every open channel should have a live peer — and reconnects any that don't, using the peer's advertised addresses. Nodes without LND are untouched; an unreachable peer is retried gently, not hammered.
+
+- **The Lightning wallet states the node's real funding state instead of "you have no channel."** Trying to send while a freshly opened channel was still waiting for on-chain confirmations — or when all its balance sits on the far side — raised a modal that claimed the node had NO channel at all (the outbound sum is legitimately zero in both states), pointed the user at opening a second channel, and — for payment routing failures — even showed the *receiving* copy. The funding gate now reads the channel list it already fetched: a confirming channel gets "it unlocks automatically once confirmed, nothing is needed from you", a far-side balance gets "you can receive, but there's nothing to send right now", a routing/liquidity payment failure says so instead of claiming channel problems, and only a genuinely channel-less node keeps the open-one guidance.
+
 ## v1.8.9-alpha (2026-09-01)

 - **Lightning sends work again after the LND 0.21.2 update.** LND 0.21 removed the old synchronous payment route the node's backend paid through (`/v1/channels/transactions`) — every Lightning send answered the literal "Not Found" and the wallet showed "Payment failed: Not Found". The backend now pays through the supported Router.SendPaymentV2 route, keeps the same settle-then-report behaviour (a slow multi-hop payment is still tracked to completion, never falsely declared failed), and translates LND's failure reasons into plain advice. A new gate test speaks the payment route directly against the running LND, so an image/backend skew like this can never ship silently again.
@@ -14,6 +22,8 @@

 - **Portainer's first-run token is in the app page, not buried in "server logs."** New Portainer versions mint a one-time setup token on a fresh install and print it only to the container logs — on an appliance that meant telling the user to go read a server log to get into their own app. The token now appears in the same launch interstitial as app login credentials (with a copy button), only while first-run setup is actually pending; once the admin account exists the card disappears on its own.

+- **The Lightning wallet states the node's real funding state instead of "you have no channel."** Trying to send while a freshly opened channel was still waiting for on-chain confirmations — or when all its balance sits on the far side — raised a modal that claimed the node had no channel at all (the outbound sum is legitimately zero in both states). The funding gate now reads the channel list it already fetched: a confirming channel gets "it unlocks automatically once confirmed, nothing is needed from you", a far-side balance gets "you can receive, but there's nothing to send right now", a routing/liquidity payment failure says so instead of pointing at channel setup, and only a genuinely channel-less node is sent to open one.
+
 ## v1.8.8-alpha (2026-09-01)

 - **SSH over the mesh is now a first-class setting.** Settings gains an "SSH over mesh" card: off by default, and when you allow it the node's mesh firewall opens port 22 — either to every mesh peer (behind an explicit "I understand" confirmation, because that's a real exposure) or only to the mesh addresses you list. The rule is owned by the node (the `90-ssh.nft` drop-in), so it survives upgrades and daemon reinstalls, and the card tells you up front whether sshd is running, whether it listens on IPv6 (the mesh is IPv6-only — this is what a broken attempt looks like before it happens), and whether password login is on (keys-only is the recommended pairing). From Termux on your phone, `fipssh <user>@<node-npub>` connects once the toggle is on — the npub is the durable address, and the command is shown with a copy button on the card.
@@ -104,7 +104,7 @@ dependencies = [

 [[package]]
 name = "archipelago"
-version = "1.8.9-alpha"
+version = "1.8.10-alpha"
 dependencies = [
 "anyhow",
 "archipelago-container",
@@ -1,6 +1,6 @@
 [package]
 name = "archipelago"
-version = "1.8.9-alpha"
+version = "1.8.10-alpha"
 edition = "2021"
 license.workspace = true
 description = "Archipelago Bitcoin Node OS - Native backend"
@@ -42,6 +42,21 @@ fn json_i64(value: &serde_json::Value, key: &str) -> Option<i64> {
    })
 }

+/// Fee budget for a send, matching lncli's own default: the payment amount
+/// (100%). Zero-amount invoices take the payer-supplied amount; fixed invoices
+/// take the invoice's own amount. Falls back to a nominal 1,000 sats only when
+/// both are somehow absent — the limit must never be left at LND's zero
+/// default, which rejects every fee-carrying route as "no route".
+fn fee_limit_sats(amount_sats: Option<u64>, decoded_amt: i64) -> i64 {
+    if let Some(amt) = amount_sats {
+        return amt as i64;
+    }
+    if decoded_amt > 0 {
+        return decoded_amt;
+    }
+    1_000
+}
+
 impl RpcHandler {
    /// Pay a Lightning invoice.
    pub(in crate::api::rpc) async fn handle_lnd_payinvoice(
@@ -107,6 +122,14 @@ impl RpcHandler {
            // enough, and it makes grpc-gateway's response a single JSON value.
            "no_inflight_updates": true,
            "timeout_seconds": 120,
+            // Router.SendPaymentV2 treats an ABSENT fee limit as ZERO — every
+            // real route carries a routing fee, so the pathfinder rejects
+            // them all and the wallet gets "No route to the recipient" on
+            // every send (fleet-wide, 2026-09-01: the v1.8.9 switch to the v2
+            // route shipped without this, and a manual lncli test that set
+            // --fee_limit masked it). lncli's own default is the payment
+            // amount (100%), which is what we send here.
+            "fee_limit_sat": fee_limit_sats(amount_sats, decoded_amt),
        });
        if let Some(amt) = amount_sats {
            pay_body["amt"] = serde_json::json!(amt.to_string());
@@ -550,4 +573,15 @@ mod tests {
            "Insufficient channel balance"
        );
    }
+
+    #[test]
+    fn fee_limit_never_falls_back_to_zero() {
+        // SendPaymentV2 defaults an ABSENT fee limit to zero — which rejects
+        // every fee-carrying route as "no route". The budget must always be
+        // positive: the payer-supplied amount for zero-amount invoices, the
+        // invoice's own amount otherwise.
+        assert_eq!(fee_limit_sats(Some(20_000), 0), 20_000);
+        assert_eq!(fee_limit_sats(None, 20_000), 20_000);
+        assert_eq!(fee_limit_sats(None, 0), 1_000);
+    }
 }
@@ -135,7 +135,7 @@ impl RpcHandler {
                // not /usr/bin/tollgate-module-basic-go — that's only the opkg/apk
                // *package* name, never an on-disk filename.
                let tollgate_installed = router
-                    .run("/usr/bin/opkg list-installed 2>/dev/null | grep -q '^tollgate-module-basic-go ' || \
+                    .run("opkg list-installed 2>/dev/null | grep -q '^tollgate-module-basic-go ' || \
                          test -f /usr/bin/tollgate-wrt 2>/dev/null")
                    .map(|(_, code)| code == 0)
                    .unwrap_or(false);
@@ -131,6 +131,10 @@ const LND_STATE_DIRS: &[&str] = &[
 /// container, not a Quadlet unit, so it is restarted via `podman`, not systemctl.
 const LND_CONTAINER: &str = "lnd";

+/// Canonical on-host admin macaroon — same path the RPC layer reads.
+const LND_ADMIN_MACAROON: &str =
+    "/var/lib/archipelago/lnd/data/chain/bitcoin/mainnet/admin.macaroon";
+
 /// Archipelago data dir (default; not overridden in prod). Holds the
 /// `user-stopped.json` that gates health-monitor auto-restart.
 const ARCHY_DATA_DIR: &str = "/var/lib/archipelago";
@@ -872,6 +876,188 @@ fn cert_sha256_thumbprint(pem: &str) -> Result<String> {
    Ok(hex::encode_upper(Sha256::digest(&der)))
 }

+// ── Channel-peer watchdog ──────────────────────────────────────────────────
+
+/// Every open channel's remote peer that is NOT currently connected.
+/// Pure over LND's REST JSON so the selection can be unit-tested.
+///
+/// `/v1/peers` uses `pub_key`; `/v1/channels` uses `remote_pubkey` — the
+/// asymmetry is LND's, not ours.
+fn select_reconnect_targets(
+    channels: &serde_json::Value,
+    peers: &serde_json::Value,
+) -> Vec<String> {
+    let connected: std::collections::HashSet<&str> = peers
+        .get("peers")
+        .and_then(|p| p.as_array())
+        .map(|arr| {
+            arr.iter()
+                .filter_map(|p| p.get("pub_key").and_then(|v| v.as_str()))
+                .collect()
+        })
+        .unwrap_or_default();
+    let mut targets: Vec<String> = channels
+        .get("channels")
+        .and_then(|c| c.as_array())
+        .map(|arr| {
+            arr.iter()
+                .filter_map(|c| c.get("remote_pubkey").and_then(|v| v.as_str()))
+                .filter(|pk| !connected.contains(pk))
+                .map(str::to_string)
+                .collect()
+        })
+        .unwrap_or_default();
+    targets.sort();
+    targets.dedup();
+    targets
+}
+
+/// Reconnect peers of open channels that LND has not re-established on its
+/// own. Returns the number of peers reconnected this pass.
+///
+/// LND normally reconnects channel peers after a restart — but not reliably:
+/// when the restart outages are long or repeated (an app update, a node
+/// reboot, reconciler churn), the peer link can stay down for hours while
+/// BOTH endpoints keep flagging the channel `disabled` in the routing
+/// graph. The node itself looks perfectly healthy and every payment in
+/// either direction fails "no route to the recipient" — observed live on
+/// framework-pt (2026-09-01): its only channel sat disabled on both policy
+/// sides for ~17h after the LND 0.21.2 update, while the wallet showed
+/// plenty of outbound. The channel graph is desired state; this keeps it.
+///
+/// Quietly returns Ok(0) when LND is not installed or its wallet is locked —
+/// that is every node without LND, on every pass.
+///
+/// `last_attempt` throttles retries per peer (`min_retry`) so an unreachable
+/// peer is not hammered every pass; the caller owns the map so the pass
+/// itself stays stateless and testable.
+pub(crate) async fn reconnect_disconnected_channel_peers(
+    last_attempt: &mut std::collections::HashMap<String, std::time::Instant>,
+    min_retry: std::time::Duration,
+) -> Result<usize> {
+    let Ok(macaroon) = read_file_as_root(LND_ADMIN_MACAROON).await else {
+        return Ok(0); // LND not installed (or not initialized yet)
+    };
+    let macaroon_hex = hex::encode(macaroon);
+    let client = reqwest::Client::builder()
+        .no_proxy()
+        .timeout(std::time::Duration::from_secs(8))
+        .danger_accept_invalid_certs(true)
+        .build()
+        .context("building LND REST client for the channel-peer watchdog")?;
+
+    let channels: serde_json::Value = client
+        .get(format!("{LND_REST_BASE_URL}/v1/channels"))
+        .header("Grpc-Metadata-macaroon", &macaroon_hex)
+        .send()
+        .await
+        .context("LND REST: listing channels for the peer watchdog")?
+        .json()
+        .await
+        .context("parsing LND channel list")?;
+    // A locked wallet answers 503 with an error body — it parses as JSON
+    // with no "channels" key, which selects nothing. That is a quiet pass.
+    let peers: serde_json::Value = client
+        .get(format!("{LND_REST_BASE_URL}/v1/peers"))
+        .header("Grpc-Metadata-macaroon", &macaroon_hex)
+        .send()
+        .await
+        .context("LND REST: listing peers for the peer watchdog")?
+        .json()
+        .await
+        .context("parsing LND peer list")?;
+
+    let mut reconnected = 0usize;
+    for pubkey in select_reconnect_targets(&channels, &peers) {
+        if last_attempt
+            .get(&pubkey)
+            .is_some_and(|t| t.elapsed() < min_retry)
+        {
+            continue;
+        }
+        last_attempt.insert(pubkey.clone(), std::time::Instant::now());
+
+        // Where does the peer live? Its advertised addresses in the public
+        // graph. A peer with none (fully private) cannot be dialed from here
+        // — LND itself may still find it; we only log the gap once per pass.
+        // Unknown to the public graph (or the graph query failed) — nothing
+        // to dial on.
+        let Ok(node) = client
+            .get(format!("{LND_REST_BASE_URL}/v1/graph/node/{pubkey}"))
+            .header("Grpc-Metadata-macaroon", &macaroon_hex)
+            .send()
+            .await
+            .and_then(|r| r.error_for_status())
+        else {
+            continue;
+        };
+        let Ok(node) = node.json::<serde_json::Value>().await else {
+            continue;
+        };
+        let addresses: Vec<String> = node
+            .get("node")
+            .and_then(|n| n.get("addresses"))
+            .and_then(|a| a.as_array())
+            .map(|arr| {
+                arr.iter()
+                    .filter_map(|a| a.get("addr").and_then(|v| v.as_str()))
+                    .map(str::to_string)
+                    .collect()
+            })
+            .unwrap_or_default();
+        if addresses.is_empty() {
+            tracing::warn!(
+                peer = %pubkey,
+                "LND channel peer is disconnected and advertises no address — cannot dial it; payments through this channel stay unroutable"
+            );
+            continue;
+        }
+
+        for addr in addresses {
+            let Some((host, port)) = addr.rsplit_once(':') else {
+                continue;
+            };
+            let Ok(port) = port.parse::<u32>() else {
+                continue;
+            };
+            let body = serde_json::json!({
+                "perm": false,
+                "timeout": "15s",
+                "addr": { "pubkey": pubkey, "host": host, "port": port },
+            });
+            match client
+                .post(format!("{LND_REST_BASE_URL}/v1/peers"))
+                .header("Grpc-Metadata-macaroon", &macaroon_hex)
+                .json(&body)
+                .send()
+                .await
+            {
+                Ok(resp) if resp.status().is_success() => {
+                    reconnected += 1;
+                    tracing::info!(
+                        peer = %pubkey,
+                        addr = %addr,
+                        "reconnected a disconnected channel peer (channel was unroutable)"
+                    );
+                    break;
+                }
+                Ok(resp) => {
+                    let msg = resp.text().await.unwrap_or_default();
+                    // Already connected between our list call and now — success.
+                    if msg.contains("already connected") {
+                        break;
+                    }
+                    tracing::debug!(peer = %pubkey, addr = %addr, %msg, "channel-peer connect attempt failed");
+                }
+                Err(e) => {
+                    tracing::debug!(peer = %pubkey, addr = %addr, error = %e, "channel-peer connect attempt failed");
+                }
+            }
+        }
+    }
+    Ok(reconnected)
+}
+
 #[cfg(test)]
 mod tests {
    use super::*;
@@ -985,4 +1171,35 @@ mod tests {
        let cands = unlock_password_candidates().await;
        assert!(cands.iter().any(|p| p == LEGACY_WALLET_PASSWORD));
    }
+
+    #[test]
+    fn reconnect_targets_pick_disconnected_channel_peers_only() {
+        // Shape captured from a live node: /v1/channels uses remote_pubkey,
+        // /v1/peers uses pub_key, and an offline channel's peer is simply
+        // absent from the peer list — that absence is the whole signal.
+        let channels = serde_json::json!({
+            "channels": [
+                { "remote_pubkey": "AAA", "active": true },
+                { "remote_pubkey": "BBB", "active": false },
+                { "remote_pubkey": "AAA" }
+            ]
+        });
+        let peers = serde_json::json!({ "peers": [ { "pub_key": "AAA" } ] });
+
+        let targets = select_reconnect_targets(&channels, &peers);
+        assert_eq!(targets, vec!["BBB".to_string()]);
+    }
+
+    #[test]
+    fn reconnect_targets_empty_without_channels_or_peers() {
+        // No LND wallet (503 error body), locked wallet, or an empty node:
+        // selects nothing, quietly.
+        let error_body = serde_json::json!({ "message": "locked" });
+        assert!(select_reconnect_targets(&error_body, &serde_json::json!({})).is_empty());
+        assert!(select_reconnect_targets(
+            &serde_json::json!({ "channels": [] }),
+            &serde_json::json!({ "peers": [] })
+        )
+        .is_empty());
+    }
 }
@@ -841,6 +841,37 @@ impl Server {
            });
        }

+        // LND channel-peer watchdog — every 2 minutes, reconnect the peers
+        // of open channels that LND has not re-established on its own. LND's
+        // reconnect logic gives up with a long backoff after repeated or
+        // extended downtime (an app update, a reboot, reconciler churn), and
+        // while the peer link is down BOTH endpoints keep the channel flagged
+        // `disabled` in the routing graph — payments fail "no route" in both
+        // directions while the node itself looks perfectly healthy. The
+        // channel graph is desired state; this keeps it (framework-pt,
+        // 2026-09-01: only channel unroutable ~17h after the 0.21.2 update).
+        // No-ops quietly on nodes without LND. Per-peer retries are throttled
+        // to 10 minutes so an unreachable peer is not hammered every pass.
+        {
+            tokio::spawn(async move {
+                let mut interval = tokio::time::interval(Duration::from_secs(120));
+                let mut last_attempt: HashMap<String, Instant> = HashMap::new();
+                loop {
+                    interval.tick().await;
+                    match crate::container::lnd::reconnect_disconnected_channel_peers(
+                        &mut last_attempt,
+                        Duration::from_secs(600),
+                    )
+                    .await
+                    {
+                        Ok(0) => {}
+                        Ok(n) => info!(n, "LND channel-peer watchdog reconnected channel peers"),
+                        Err(e) => debug!("LND channel-peer watchdog (non-fatal): {}", e),
+                    }
+                }
+            });
+        }
+
        // FIPS seed-anchor apply loop — every 5 minutes we re-push the
        // configured seed anchors into the running fips daemon via
        // `fipsctl connect`. This keeps the mesh bootstrap resilient:
@@ -15,25 +15,32 @@ pub enum PkgManager {
 impl Router {
    /// Detect which package manager is available.
    ///
-    /// - If `/usr/bin/opkg` exists → `PkgManager::Opkg` (nothing to do).
-    /// - If `/usr/bin/apk` exists → run `apk update` (switching repos to HTTP
+    /// Looks up `opkg`/`apk` via the router's `$PATH` (`command -v`) rather
+    /// than a hardcoded `/usr/bin/<tool>` — official OpenWrt images don't all
+    /// symlink `/bin` into `/usr/bin` (e.g. the `glinet_gl-mt3000` 24.10.2
+    /// build keeps them as separate real directories with `opkg` living in
+    /// `/bin`), so a fixed absolute path silently misses a perfectly normal
+    /// install and reports "no package management" (archy-x250-pa3, 2026-09-05).
+    ///
+    /// - If `opkg` is on PATH → `PkgManager::Opkg` (nothing to do).
+    /// - If `apk` is on PATH → run `apk update` (switching repos to HTTP
    ///   first to work around missing CA bundle on fresh images), then try
    ///   `apk add opkg`.  If opkg is in the repos → `Opkg`.  If not (OpenWrt
    ///   25.x) → `ApkNative`.
    /// - Neither found → error.
    pub fn opkg_check(&self) -> Result<PkgManager> {
-        let (_, code) = self.run("test -x /usr/bin/opkg")?;
+        let (_, code) = self.run("command -v opkg >/dev/null 2>&1")?;
        if code == 0 {
            return Ok(PkgManager::Opkg);
        }

-        let (_, apk_code) = self.run("test -x /usr/bin/apk")?;
+        let (_, apk_code) = self.run("command -v apk >/dev/null 2>&1")?;
        if apk_code == 0 {
            info!("[{}] opkg not found — using apk (OpenWrt 25.x+)", self.host);
            // Fresh images ship without a CA bundle; switch repos to HTTP so
            // apk's wget can reach the package index without TLS verification.
            self.run_ok("sed -i 's|https://|http://|g' /etc/apk/repositories 2>/dev/null || true")?;
-            let (update_out, update_code) = self.run("/usr/bin/apk update 2>&1")?;
+            let (update_out, update_code) = self.run("apk update 2>&1")?;
            if update_code != 0 {
                anyhow::bail!(
                    "apk update failed (exit {}) — router may have no internet access. \
@@ -43,7 +50,7 @@ impl Router {
                );
            }
            // Try to install opkg (only available on some 25.x builds).
-            let (add_out, add_code) = self.run("/usr/bin/apk add opkg 2>&1")?;
+            let (add_out, add_code) = self.run("apk add opkg 2>&1")?;
            if add_code == 0 {
                return Ok(PkgManager::Opkg);
            }
@@ -62,7 +69,7 @@ impl Router {
        }

        anyhow::bail!(
-            "opkg not found at /usr/bin/opkg — this router's firmware may not \
+            "Neither opkg nor apk found on this router's $PATH — its firmware may not \
             support package management (TollGate requires a standard OpenWrt build)"
        );
    }
@@ -70,31 +77,28 @@ impl Router {
    /// `opkg update` — refresh package lists.
    pub fn opkg_update(&self) -> Result<()> {
        info!("[{}] opkg update", self.host);
-        self.run_ok("/usr/bin/opkg update")?;
+        self.run_ok("opkg update")?;
        Ok(())
    }

    /// Install a package, skipping if already installed.
    pub fn opkg_install(&self, package: &str) -> Result<()> {
        // Check if already installed to avoid unnecessary network traffic.
-        let (_, code) = self.run(&format!(
-            "/usr/bin/opkg list-installed | grep -q '^{} '",
-            package
-        ))?;
+        let (_, code) = self.run(&format!("opkg list-installed | grep -q '^{} '", package))?;
        if code == 0 {
            info!("[{}] {} already installed", self.host, package);
            return Ok(());
        }

        info!("[{}] opkg install {}", self.host, package);
-        self.run_ok(&format!("/usr/bin/opkg install {}", package))?;
+        self.run_ok(&format!("opkg install {}", package))?;
        Ok(())
    }

    /// Remove a package.
    pub fn opkg_remove(&self, package: &str) -> Result<()> {
        info!("[{}] opkg remove {}", self.host, package);
-        self.run_ok(&format!("/usr/bin/opkg remove {}", package))?;
+        self.run_ok(&format!("opkg remove {}", package))?;
        Ok(())
    }

@@ -121,7 +125,7 @@ impl Router {
        }

        info!("[{}] apk add {}", self.host, package);
-        self.run_ok(&format!("/usr/bin/apk add {}", package))?;
+        self.run_ok(&format!("apk add {}", package))?;
        Ok(())
    }
 }
@@ -6,18 +6,53 @@ use crate::Router;
 /// The OpenWrt package name for the TollGate reference implementation.
 const TOLLGATE_PACKAGE: &str = "tollgate-module-basic-go";

-/// Direct-download fallback URLs by opkg architecture string.
+/// Pinned upstream release. Was stuck on v0.2.0 (Oct 2025) until 2026-09-05 —
+/// nine releases behind. v0.5.0's changelog covers exactly the failure modes
+/// hit live against archy-x250-pa3: a mint with an empty/broken keyset used
+/// to crash-loop the daemon forever ("graceful degradation when Cashu mints
+/// fail" in v0.5.0), and the bundled captive-portal build had no CBOR support
+/// at all, so it could only decode legacy `cashuA` tokens — rejecting the
+/// `cashuB` (NUT-00 V4) tokens modern wallets like Minibits generate by
+/// default ("portal improvements" in v0.5.0 include a JS bundle update that
+/// should carry a current cashu-ts with V4 support). Bump this string to move
+/// both this crate's URLs and the version baked into the source comments.
+const TOLLGATE_VERSION: &str = "v0.5.0";
+
+/// Direct-download fallback URLs by opkg architecture string, for the
+/// `.ipk` (ar-archive) package format.
 /// Used when the package is not in any configured feed.
-/// Source: https://github.com/OpenTollGate/tollgate-module-basic-go/releases/tag/v0.2.0
-fn ipk_url(arch: &str) -> Option<&'static str> {
-    match arch {
-        "mips_24kc"          => Some("https://github.com/OpenTollGate/tollgate-module-basic-go/releases/download/v0.2.0/mips_24kc.ipk"),
-        "mipsel_24kc"        => Some("https://github.com/OpenTollGate/tollgate-module-basic-go/releases/download/v0.2.0/mipsel_24kc.ipk"),
-        "aarch64_cortex-a53" => Some("https://github.com/OpenTollGate/tollgate-module-basic-go/releases/download/v0.2.0/aarch64_cortex-a53.ipk"),
-        "aarch64_cortex-a72" => Some("https://github.com/OpenTollGate/tollgate-module-basic-go/releases/download/v0.2.0/aarch64_cortex-a72.ipk"),
-        "arm_cortex-a7"      => Some("https://github.com/OpenTollGate/tollgate-module-basic-go/releases/download/v0.2.0/arm_cortex-a7.ipk"),
-        _ => None,
-    }
+/// Source: https://github.com/OpenTollGate/tollgate-module-basic-go/releases/tag/v0.5.0
+fn ipk_url(arch: &str) -> Option<String> {
+    let name = match arch {
+        "mips_24kc"          => "mips_24kc",
+        "mipsel_24kc"        => "mipsel_24kc",
+        "aarch64_cortex-a53" => "aarch64_cortex-a53",
+        "aarch64_cortex-a72" => "aarch64_cortex-a72",
+        "arm_cortex-a7"      => "arm_cortex-a7",
+        "x86_64"             => "x86_64",
+        _ => return None,
+    };
+    Some(format!(
+        "https://github.com/OpenTollGate/tollgate-module-basic-go/releases/download/{TOLLGATE_VERSION}/tollgate-wrt_{TOLLGATE_VERSION}_{name}.ipk"
+    ))
+}
+
+/// Direct-download URLs for the native Alpine-style `.apk` package format —
+/// only published for a subset of architectures as of v0.5.0. Where
+/// available this is strictly better than [`ipk_url`] on an apk-native
+/// (OpenWrt 25.x+) router: `apk add` installs it directly (dependency
+/// resolution, postinst, uci-defaults all handled by apk itself), instead of
+/// the manual `ar`/`tar` extraction dance `install_ipk` has to do to unpack
+/// an `.ipk` on a router with no `opkg`.
+fn apk_url(arch: &str) -> Option<String> {
+    let name = match arch {
+        "aarch64_cortex-a53" => "aarch64_cortex-a53",
+        "x86_64" => "x86_64",
+        _ => return None,
+    };
+    Some(format!(
+        "https://github.com/OpenTollGate/tollgate-module-basic-go/releases/download/{TOLLGATE_VERSION}/tollgate-wrt_{TOLLGATE_VERSION}_{name}.apk"
+    ))
 }

 /// Install tollgate-module-basic-go via opkg (OpenWrt ≤24.x).
@@ -35,7 +70,7 @@ pub fn install_tollgate(router: &Router) -> Result<()> {

    // Package not in any feed — download the .ipk directly.
    let arch = router
-        .run_ok("/usr/bin/opkg print-architecture | grep -v all | grep -v noarch | tail -1 | awk '{print $2}'")?;
+        .run_ok("opkg print-architecture | grep -v all | grep -v noarch | tail -1 | awk '{print $2}'")?;
    let arch = arch.trim();

    let url = ipk_url(arch).ok_or_else(|| {
@@ -88,7 +123,7 @@ pub fn install_tollgate_apk_native(router: &Router) -> Result<()> {
        ". /etc/openwrt_release 2>/dev/null \
         && a=\"${DISTRIB_ARCH:-${OPENWRT_ARCH:-}}\" \
         && [ -n \"$a\" ] && echo \"$a\" \
-         || /usr/bin/apk --print-arch 2>/dev/null \
+         || apk --print-arch 2>/dev/null \
         || uname -m",
    )?;
    // Normalise: uname -m returns bare "mipsel"/"mips"; map to 24kc variant
@@ -103,6 +138,39 @@ pub fn install_tollgate_apk_native(router: &Router) -> Result<()> {
        anyhow::bail!("Could not determine router architecture");
    }

+    // Prefer a native .apk when the release publishes one for this arch —
+    // `apk add` handles the install itself (deps, postinst, uci-defaults),
+    // skipping the manual ar/tar extraction the .ipk fallback below needs.
+    if let Some(url) = apk_url(arch) {
+        info!(
+            "[{}] Downloading native TollGate .apk for {} from GitHub releases",
+            router.host, arch
+        );
+        let (dl_out, dl_code) = router.run(&format!(
+            "wget --no-check-certificate -O /tmp/tollgate.apk '{}' 2>&1",
+            url
+        ))?;
+        if dl_code != 0 {
+            anyhow::bail!("TollGate .apk download failed: {}", dl_out.trim());
+        }
+        let (size_out, _) = router.run("wc -c < /tmp/tollgate.apk 2>/dev/null")?;
+        let size: u64 = size_out.trim().parse().unwrap_or(0);
+        if size < 50_000 {
+            anyhow::bail!(
+                "Downloaded TollGate .apk is only {}B — wget likely captured an error page. \
+                 Check router internet access and that the release URL is reachable.",
+                size
+            );
+        }
+        let (add_out, add_code) =
+            router.run("apk add --allow-untrusted /tmp/tollgate.apk 2>&1")?;
+        router.run_ok("rm -f /tmp/tollgate.apk")?;
+        if add_code != 0 {
+            anyhow::bail!("TollGate .apk install failed: {}", add_out.trim());
+        }
+        return Ok(());
+    }
+
    let url = ipk_url(arch).ok_or_else(|| {
        anyhow::anyhow!(
            "No pre-built TollGate package for architecture '{}'. \
@@ -10,6 +10,7 @@ disagree, the code wins and the doc is a bug.
 - [Talking to your node](COMMANDS.md) — the conversational command surface
 - [Seed Verification](SEED-VERIFICATION.md) — independently verify your 24-word backup
 - [Troubleshooting](troubleshooting.md) — common problems and how to resolve them
+- [OpenWrt Gateway Setup](openwrt-gateway-setup.md) — pairing an OpenWrt router and provisioning TollGate pay-as-you-go WiFi
 - [Gamepad / Controller Navigation](GAMEPAD-NAV.md) — driving the UI from a controller
 - [Pine voice commands](pine-voice-commands.md) — the voice-satellite phrase surface

@@ -52,13 +52,55 @@ built and verified to embed the alias fix. `cargo fmt` applied.
 | D1 shorty NPM crash-loop stopped cleanly (user-stopped marker; public hosts keep serving via host nginx mirror) | ✅ 12:52Z |
 | D2 shorty live nginx HSTS patch + reload | ✅ verified: :80 and :443 both answer `max-age=0` |
 | D3 Regenerate catalog (releases/app-catalog.json + store copies) | ✅ semantic diff = exactly the two NPM fixes |
-| D4 **User runs `scripts/sign-catalog.sh`** (signer built at /tmp/archy-sign-bin) | ⬜ waiting on mnemonic |
-| D5 Commit + push (origin + gitea-vps2 OTA mirror) | ✅ 6 commits pushed (signed catalog commits after D4) |
-| D6 Release v1.8.9-alpha: `scripts/create-release.sh 1.8.9-alpha` (mnemonic) → `scripts/publish-release-assets.sh 1.8.9-alpha gitea-vps2` | ⬜ waiting on mnemonic |
-| D7 OTA on shorty-s + framework-pt (Update button; framework-pt has no SSH from here) | ⬜ |
-| D8 shorty: clear the NPM user-stopped marker + Start (or it starts via the fixed catalog) | ⬜ |
+| D4 **User runs `scripts/sign-catalog.sh`** (signer built at /tmp/archy-sign-bin) | ✅ catalog signed + committed + pushed |
+| D5 Commit + push (origin + gitea-vps2 OTA mirror) | ✅ 9 commits pushed |
+| D6 Release v1.8.9-alpha: `scripts/create-release.sh 1.8.9-alpha` (mnemonic) → `scripts/publish-release-assets.sh 1.8.9-alpha gitea-vps2` | ✅ PUBLISHED (tag v1.8.9-alpha, releases/manifest.json live, backend+frontend assets verified by the script) |
+| D7 OTA on shorty-s + framework-pt (Update button; shorty is on 1.8.8-alpha, daily check — hit Update now) | ⬜ user action |
+| D8 shorty: clear the NPM user-stopped marker + Start (or it starts via the fixed catalog) | ✅ NPM LIVE-HEALED via the signed catalog: unit regenerated with both fixes, container up, admin UI HTTP 200 on :8081 (verified 15:42Z) |
 | D9 framework-pt: Start Mempool — its containers are confirmed stopped (port 4080 refuses; gate answers on 7778/8334/50002/18083 so those apps will embed over https immediately) | ⬜ |
-| D10 Post-deploy live checks: LND send+receive; mempool/IndeeHub/bitcoin-UI frames over https; NPM healthy + admin :8081; portainer token card on fresh DB; zero CORS errors | ⬜ |
+| D10 Post-deploy live checks: LND send+receive; mempool/IndeeHub/bitcoin-UI frames over https; NPM healthy + admin :8081 ✅; portainer token card on fresh DB; zero CORS errors | ⬜ after nodes update |
+
+## E. Follow-ups discovered during the incident (ride the NEXT release, v1.8.10+)
+
+- **LND channel-peer watchdog** (this release's headline platform fix): every
+  2 minutes the daemon reconnects peers of open channels that LND has not
+  re-established on its own (per-peer retry throttled to 10 minutes), using
+  the peer's advertised addresses from the public graph. Kills the whole
+  class this incident exposed — a channel unroutable ~17h after an LND update
+  while both nodes looked healthy. Unit tests pin the selection logic over the
+  live REST shapes.
+- **Funding-modal honesty fix** (1464b1b2): the
+  Lightning "no channel" modal now states the node's real state — pending
+  channel confirming / balance on the far side / payment couldn't route /
+  genuinely no channels. Note the stale-direction defect it fixes: the
+  payment-failure mapper never set the direction, so a SEND failure showed
+  the RECEIVE-branch copy ("Receiving needs inbound liquidity…") — the exact
+  modal users saw while their node had a healthy 583k-outbound channel.
+  Both fixes have their v1.8.10 CHANGELOG + What's New entries staged so the
+  next `create-release.sh 1.8.10-alpha` runs clean first time.
+- Nodes poll for OTA updates on `daily_check` — after publishing, tell the
+  user to hit Update rather than wait for the next check.
+- `origin` remote had a stale pushurl with a dead token (pushes failed);
+  fixed to the canonical repo URL, stale `~/.git-credentials` entry with an
+  encoded port removed.
+
+## F. Post-v1.8.9 verification on shorty-s (2026-09-01 evening)
+
+- v1.8.9 applied; payment pipeline confirmed live: a 400,000 sat payment
+  SUCCEEDED through the v2 router route; the 404s are gone.
+- App gate serves TLS on 4080/8334/18083/50002 (401 gate pages over https) —
+  https app frames now answer. Mempool over https requires a hard refresh
+  (PWA precaches the old bundle).
+- **"No route to the recipient" on sends is real**: the invoices being tested
+  are from framework-pt, whose only channel (peer "Sandwich Farm",
+  0224c955…) is flagged `disabled` on BOTH policy sides in the routing graph
+  after today's node churn — the peer connection never re-established
+  (LND's reconnect backoff can stretch to hours). A disabled edge is
+  unroutable in both directions, so payments to/from framework-pt fail
+  regardless of shorty's 583k outbound. Fix: `lncli connect` the peer, wait
+  for the channel_update to re-enable the edge (~minutes), then re-test.
+- The 577k attempt earlier failed for a different, correct reason: it exceeded
+  the channel's spendable balance (583,542 − 9,850 reserve ≈ 573k max).

 framework-pt immediate workaround until its OTA lands: open the dashboard by
 IP (`http://192.168.x.x`) instead of `framework-pt.local`, and/or clear the
@@ -0,0 +1,299 @@
+# OpenWrt Gateway Setup
+
+How to connect an OpenWrt router to an Archipelago node and, optionally, turn
+it into a pay-as-you-go WiFi gateway with **TollGate**. Written for a node
+operator following the UI; a developer-facing RPC/architecture reference is
+at the bottom.
+
+This feature manages a **separate physical (or virtual) router** running
+OpenWrt over SSH/UCI — it is not a containerized app. Archipelago itself does
+not flash or install OpenWrt; you bring a router that already runs it.
+
+## What you get
+
+- **Status dashboard**: hostname, uptime, firmware release, WiFi interfaces,
+  WAN state — polled live from the router.
+- **WAN/WISP wizard**: point the router's radio at an upstream WiFi network
+  (turns it into a wireless bridge/repeater) with DHCP + NAT configured for
+  you.
+- **TollGate provisioning** (optional): installs the
+  [TollGate](https://tollgate.me) captive-portal package
+  (`tollgate-module-basic-go`) and stands up an `archipelago` SSID that
+  sells timed internet access for sats, settled against this node's local
+  Cashu mint.
+
+## Prerequisites
+
+1. **A router already flashed with OpenWrt.** Check the
+   [OpenWrt Table of Hardware](https://openwrt.org/toh/start) for your model
+   and follow OpenWrt's own install/flashing instructions — that part is
+   outside Archipelago's scope. See below for a worked example (GL.iNet
+   AX3000).
+2. **SSH reachable.** Fresh OpenWrt images enable `dropbear` (SSH) on LAN by
+   default, listening as `root` with no password (or the password you set
+   during OpenWrt's first-boot wizard at `192.168.1.1`). Archipelago
+   connects with `ssh2` over a password (key-based auth is supported at the
+   library level but the UI only offers password so far).
+3. **Same LAN as the Archipelago node**, at least for setup — plug the
+   router's LAN port into the same switch/network segment the node is on.
+4. **For TollGate**: a running Cashu mint app (`nutshell`/`cashu-mint`) on
+   this node — provisioning defaults `mint_url` to
+   `http://<node-ip>:3338` and TollGate customers must be able to reach that
+   URL from outside the node's loopback.
+
+## Worked example: flashing a GL.iNet AX3000 to stock OpenWrt
+
+GL.iNet's "AX3000" travel router is the **Beryl AX (GL-MT3000)** —
+MediaTek MT7981B (Cortex-A53), OpenWrt target `mediatek/filogic`. It ships
+running a GL.iNet fork of OpenWrt with its own web UI and LuCI already
+enabled, but the steps below replace that with stock/vanilla OpenWrt so it
+matches the prebuilt TollGate `.ipk` architectures exactly
+(`aarch64_cortex-a53`).
+
+1. **Download the sysupgrade image** for the current stable release from
+   `https://downloads.openwrt.org/releases/<version>/targets/mediatek/filogic/`
+   — the file you want is
+   `openwrt-<version>-mediatek-filogic-glinet_gl-mt3000-squashfs-sysupgrade.bin`.
+2. **Verify the checksum** against the `sha256sums` file in that same
+   directory before flashing anything.
+3. **Flash from the GL.iNet UI**: on the router's default address
+   (`192.168.8.1`), go to **More Settings → Upgrade → Local Upgrade**, or
+   open **Advanced → LuCI** and use **System → Backup / Flash Firmware →
+   Flash new firmware image**.
+4. Upload the `.bin` file. **Uncheck "Keep Settings"** — going from the
+   GL.iNet fork to stock OpenWrt needs a clean reset, not a config carry-over.
+5. Confirm and wait ~3–5 minutes without power-cycling the router.
+6. **After it reboots** you're on stock OpenWrt: LAN at `192.168.1.1`, DHCP
+   on, SSH (dropbear) open as `root` with **no password set yet** — set one
+   via LuCI at `192.168.1.1` or `passwd` over SSH before doing anything else.
+   From here, continue with the Prerequisites/Step 2 flow above to connect
+   it to the Archipelago node.
+
+   > The Archipelago UI's Connect form (Step 2) authenticates *with* a
+   > password — it has no flow for setting the initial one on a fresh,
+   > passwordless router. You have to set it out-of-band first. If you're
+   > working from the node's own local kiosk display rather than a normal
+   > desktop browser, there's no visible tab bar/address bar to open a new
+   > tab from — press **Ctrl+T** to open one anyway, navigate to
+   > `192.168.1.1`, and use LuCI's first-boot prompt to set the root
+   > password. Then switch back to the Archipelago tab and Connect with it.
+
+**If the flash fails / the router doesn't come back**: filogic devices
+don't use a reset-button recovery. Instead, connect to the router's LAN
+port and, during boot, press a key within the first ~2 seconds to enter
+U-Boot; per the OpenWrt wiki, typing `gl` then `httpd` at the U-Boot prompt
+brings up a recovery web UI at `192.168.1.2` that accepts a firmware image.
+
+## Step 1: Open the OpenWrt Gateway panel
+
+1. In the Archipelago UI, go to **Server**.
+2. Under the network status list, click **OpenWrt Gateway**
+   (`/dashboard/server/openwrt`).
+
+If no router has been connected before, you'll land on the connect form.
+
+## Step 2: Connect the router
+
+You have two options:
+
+- **Detect**: click **Detect** — this reads the node's own active wired
+  Ethernet interface, derives its subnet, and probes every host on it for
+  `TCP/22` + a valid `/etc/openwrt_release`. If it finds exactly one router
+  it fills in the host automatically; if it finds several you pick from the
+  list. A `/24` scan can take up to ~2 minutes (255 sequential probes at
+  500 ms each on hosts that don't respond).
+- **Manual**: type the router's LAN IP (commonly `192.168.1.1` on a router
+  freshly bridged in, or whatever address it has on your network) plus the
+  SSH username (default `root`) and password.
+
+Click **Connect**. On success the panel switches to the status dashboard and
+the connection (host + credentials) is persisted server-side — you won't
+need to re-enter them on future visits or from other views (e.g. the Home
+dashboard's network tile also polls this without prompting again).
+
+> Credentials are stored in `router_config.json` under the node's data
+> directory alongside other node config. There's no separate secrets
+> vault entry for this yet — treat the router's SSH password like any other
+> node-local config.
+
+## Step 3: (Optional) Configure WAN/WISP
+
+Use this to make the OpenWrt router pull its internet connection from an
+upstream WiFi network instead of a wired uplink — useful for a
+battery/off-grid TollGate node or extending coverage from an existing
+network.
+
+1. From the status dashboard, start the **WAN setup** wizard.
+2. **Scan** — the router's radio scans for visible networks (a few seconds
+   of SSH round-trips).
+3. **Select network** — pick the upstream SSID from the list.
+4. **Password** — enter the upstream network's WiFi password (encryption
+   defaults to `psk2`; leave blank only for open networks).
+5. **DHCP / NAT** — review the LAN DHCP pool (default `.100`–`.249`) and
+   whether to enable NAT/masquerade on the WAN zone (leave this on unless
+   you have a specific reason not to).
+6. **Connect** — this writes a `wwan` STA `wifi-iface` + `network` interface
+   over UCI, enables the radio if it was disabled (OpenWrt ships with
+   `radio0.disabled=1` on a fresh flash), and adds `wwan` to the WAN
+   firewall zone.
+
+The dashboard's WAN panel shows the resulting association state, assigned
+IP, and whether the router currently has internet reachability.
+
+## Step 4: (Optional) Install TollGate
+
+Once connected (and with a local Cashu mint app running), the dashboard
+shows a **TollGate: not installed** panel with a single **Install TollGate**
+button — there's no config form at this stage, it installs with defaults.
+The panel itself warns: *"Router needs internet access to install TollGate
+— configure WAN above first"* (Step 3), since the router has to reach the
+internet to download the package.
+
+1. Click **Install TollGate**. The button relabels to *"Installing… this
+   may take a few minutes"* while it works.
+2. Under the hood this installs `tollgate-module-basic-go` on the router
+   (via `opkg` on OpenWrt ≤24.x, or a manual `.ipk` extract on 25.x images
+   where `opkg` isn't available), writes `/etc/tollgate/config.json`, and
+   creates the `archipelago` SSID — all with default pricing (10 sats per
+   1-minute step, minimum 1 step, `mint_url` auto-filled to
+   `http://<node-ip>:3338`, enabled).
+3. On success you'll see *"TollGate provisioned successfully"* and the
+   panel switches to the installed view (Enabled/Disabled badge, current
+   price/step/mint).
+
+### Configuring price, step size, or mint (after install)
+
+The installed-state panel has an **Edit** button — this is the only place
+you set price/step/mint, and it only appears once TollGate is already
+installed:
+
+1. Click **Edit**.
+2. Set **Price** (sats), **Step size** (minutes — billed as `step_size_ms`
+   under the hood), **Minimum steps** a customer must buy at once, **Mint
+   URL** (leave as the auto-filled node URL unless pointing at an external
+   mint), and the **Enable TollGate** toggle.
+3. Click **Save**. Changes are pushed to `/etc/tollgate/config.json` and the
+   daemon is restarted to pick them up — it does not hot-reload.
+
+Anyone who joins the `archipelago` SSID sees TollGate's captive portal and
+pays sats (via the configured Cashu mint) for timed access.
+
+## Verifying a successful install
+
+A clean install (flash → Connect → WAN/WISP → Install TollGate, all through
+the UI as above) ends in this state — worth checking if you want to confirm
+everything actually landed correctly rather than trusting the UI's success
+toast alone:
+
+- `tollgate-wrt` is running (`/etc/init.d/tollgate-wrt status` → `running`).
+- nodogsplash's **rendered** config — not just the UCI source — has
+  `GatewayInterface br-tollgate`. Check the actual file the daemon was
+  started with (typically `/tmp/etc/nodogsplash_main.conf`), since that's
+  what's actually enforced, not `uci show nodogsplash`. This matters because
+  provisioning must stop nodogsplash and reconfigure it to gate the
+  `br-tollgate` bridge *before* starting it — installing the package by hand
+  (bypassing the UI/RPC flow) leaves nodogsplash on its default
+  `br-lan`-gating behavior instead, which locks out the router's own
+  admin/SSH access. If you ever see a router become unreachable right after
+  a TollGate install, this is the first thing to check.
+- The router's own LAN (the interface you manage it over — SSH, ping) is
+  still reachable and untouched by the portal.
+- TollGate's own log (`logread | grep tollgate-wrt`) shows successful mint
+  probes for each configured mint.
+
+A `dev build detected (branch=unknown), injecting test mint:
+https://nofee.testnut.cashu.space` line in that log means the installed
+build considers itself a dev build and silently adds a test mint alongside
+your configured one(s) — check the Edit panel's Mint URL afterward if you
+don't want that test mint accepted.
+
+### A note on network topology during setup
+
+If the Archipelago node reaches the router over the same wired interface the
+router uses as its LAN, expect the router to become the node's default
+route on that interface once it has its own working WAN/WISP uplink — this
+is normal and, once WAN is actually configured with internet access, works
+fine end-to-end (the node's traffic routes out through the router's
+uplink). It's only a problem *before* WAN is configured: a freshly flashed
+or freshly factory-reset router has no upstream internet yet, so if it wins
+the node's default-route race (lowest metric on its own interface) while
+still offline, it creates a dead-end route and the node loses its own
+connectivity (including anything tunneled, e.g. a VPN/mesh network the node
+relies on) until that route is removed or the router gets its uplink
+working. If you hit this, either wait until WAN/WISP is actually up before
+letting the router's interface win the route race, or temporarily lower the
+priority of that route until it is.
+
+## Reconfiguring or moving to a different router
+
+Use **Disconnect** on the status dashboard to return to the connect form —
+this only clears the panel's client-side state, it doesn't delete the
+persisted `router_config.json`, so reconnecting to the same router needs no
+re-entry. To point at a *different* router, disconnect and connect with a
+new host/credentials; the newly connected router becomes the persisted one.
+
+## Troubleshooting
+
+- **"No router configured"**: nothing has been connected yet, or the saved
+  config didn't include a host — go through Step 2 again.
+- **Connect hangs or times out**: the router isn't reachable on `TCP/22`
+  from the node's network, or SSH auth failed. Confirm you can `ssh
+  root@<router-ip>` manually from the node (or a machine on the same LAN)
+  with the same credentials.
+- **Router "moved networks" / stale saved host**: SSH/status calls are
+  bounded (5s TCP connect, 30s read/write) precisely so an unreachable
+  saved router can't stall other RPCs — but the dashboard will show a
+  connection error until you reconnect with the router's current address.
+- **TollGate provision fails with "No pre-built TollGate package for
+  architecture..."**: your router's SoC isn't one of the prebuilt
+  `.ipk` targets (`mips_24kc`, `mipsel_24kc`, `aarch64_cortex-a53`,
+  `aarch64_cortex-a72`, `arm_cortex-a7`). You'll need a custom opkg feed or
+  to build `tollgate-module-basic-go` from source for your architecture.
+- **TollGate download looks like it succeeded but provisioning still
+  fails**: the node sanity-checks the downloaded `.ipk` is at least 50 KB —
+  a smaller file usually means `wget` captured an HTML error page instead
+  (no internet access from the router, or a bad release URL).
+- **Install fails right after a reboot or a fresh WAN setup** with `apk
+  update failed ... router may have no internet access` even though WAN
+  looks configured: this is usually just timing, not a real problem — the
+  router's WiFi-uplink association (`wwan`/`hakodosh`-style STA interface)
+  can take a few seconds longer to reconnect than the dashboard takes to
+  let you click Install. Wait ~10–15 seconds after WAN shows `sta_state:
+  up` and retry; it should succeed on the next attempt.
+- **Install fails with `opkg not found at /usr/bin/opkg` (or similar) even
+  though the router clearly has `opkg`/`apk` installed**: fixed as of
+  2026-09-05 — the backend used to hardcode `/usr/bin/opkg`/`/usr/bin/apk`,
+  which some official OpenWrt builds don't symlink into `/bin`. If you're
+  running an Archipelago build from before that fix, update first.
+
+---
+
+## Developer reference
+
+Backend crate: `core/openwrt` (`archipelago-openwrt`) — SSH/UCI plumbing,
+WAN/WISP config, WiFi scanning, and TollGate install/config. See
+[`architecture.md`](architecture.md) for where it sits in the workspace.
+
+RPC methods (`core/archipelago/src/api/rpc/openwrt.rs`, dispatched in
+`core/archipelago/src/api/rpc/dispatcher.rs`):
+
+| Method | Purpose |
+|---|---|
+| `openwrt.scan` | Probe a subnet for OpenWrt routers (`subnet`, `prefix`, `ssh_user`, `ssh_password`) |
+| `openwrt.get-status` | Full status: release, WiFi interfaces, WAN, TollGate state. No params → uses saved `router_config.json`; params with `host` also persist the connection |
+| `openwrt.configure-wan` | Write WISP/WAN config (`ssid`, `password`, `encryption`, `dhcp_start`, `dhcp_limit`, `masq`) |
+| `openwrt.scan-wifi` | Radio scan for visible upstream networks |
+| `openwrt.provision-tollgate` | Install/reconfigure TollGate (`price_sats`, `step_size_ms`, `min_steps`, `mint_url`, `enabled`) |
+
+Note: these are distinct from the unrelated `router.*` methods
+(`router.discover`, `router.configure`, `router.list-forwards`, ...), which
+handle UPnP/NAT-PMP port forwarding on the node's own upstream home router —
+not the OpenWrt gateway feature described here.
+
+Frontend: `neode-ui/src/views/server/OpenWrtGateway.vue`, routed at
+`server/openwrt` (`neode-ui/src/router/index.ts`), linked from
+`neode-ui/src/views/Server.vue`.
+
+Persisted connection state: `router_config.json` in the node's data
+directory (`core/archipelago/src/network/router.rs`:
+`load_router_config`/`save_router_config`).
@@ -1,12 +1,12 @@
 {
  "name": "neode-ui",
-  "version": "1.8.9-alpha",
+  "version": "1.8.10-alpha",
  "lockfileVersion": 3,
  "requires": true,
  "packages": {
    "": {
      "name": "neode-ui",
-      "version": "1.8.9-alpha",
+      "version": "1.8.10-alpha",
      "dependencies": {
        "@scure/bip39": "^2.2.0",
        "@types/dompurify": "^3.0.5",
@@ -1,7 +1,7 @@
 {
  "name": "neode-ui",
  "private": true,
-  "version": "1.8.9-alpha",
+  "version": "1.8.10-alpha",
  "type": "module",
  "scripts": {
    "start": "./start-dev.sh",
@@ -10,7 +10,32 @@
    z-index="z-[3600]"
    @close="onClose"
  >
-    <p v-if="lightning.status.value === 'no-funds'" class="text-sm text-white/70 leading-relaxed">
+    <p v-if="lightning.status.value === 'no-funds' && lightning.fundingReason.value === 'pending'" class="text-sm text-white/70 leading-relaxed">
+      Your new channel is <span class="text-white/90">waiting for its on-chain confirmations</span> —
+      that's why the network doesn't see it yet. It unlocks automatically once
+      confirmed (usually within about half an hour); nothing is needed from
+      you. This screen will work as soon as it lands.
+    </p>
+    <p v-else-if="lightning.status.value === 'no-funds' && lightning.fundingReason.value === 'far-side'" class="text-sm text-white/70 leading-relaxed">
+      <template v-if="lightning.fundingDirection.value === 'receive'">
+        You have channels, but <span class="text-white/90">all the balance is on your side</span> —
+        you can send, but there's nothing to be paid into right now. Receive a
+        payment by spending first, or open another channel to bring inbound
+        liquidity in.
+      </template>
+      <template v-else>
+        You have channels, but <span class="text-white/90">all the balance is on the far side</span> —
+        you can receive, but there's nothing to send right now. Someone has to
+        pay you first (or rebalance the channel), and sending unlocks on its own.
+      </template>
+    </p>
+    <p v-else-if="lightning.status.value === 'no-funds' && lightning.fundingReason.value === 'failed-payment'" class="text-sm text-white/70 leading-relaxed">
+      LND couldn't route this payment — most often there's
+      <span class="text-white/90">not enough outbound for this amount</span>, or no
+      route to the recipient at the fees offered. Smaller amounts sometimes
+      get through; check the channels screen to see what's actually spendable.
+    </p>
+    <p v-else-if="lightning.status.value === 'no-funds'" class="text-sm text-white/70 leading-relaxed">
      Your Lightning node is running, but it has no payment channel yet.
      <template v-if="lightning.fundingDirection.value === 'receive'">
        Receiving needs <span class="text-white/90">inbound liquidity</span> — a
@@ -101,14 +126,31 @@
        @click="openApps"
      >Open My Apps</button>
      <template v-else-if="lightning.status.value === 'no-funds'">
-        <button
-          class="flex-1 glass-button px-4 py-2 rounded-lg text-sm"
-          @click="openSetupGuide"
-        >Setup Guide</button>
-        <button
-          class="flex-1 glass-button glass-button-warning px-4 py-2 rounded-lg text-sm font-medium"
-          @click="openLightningSetup"
-        >Open a channel</button>
+        <!-- A confirming channel needs no action at all — offering "open a
+             channel" here would send the user to fix a problem they don't
+             have (and possibly open a second one). -->
+        <template v-if="lightning.fundingReason.value === 'pending'">
+          <button
+            class="flex-1 glass-button px-4 py-2 rounded-lg text-sm"
+            @click="onClose"
+          >Got it — I'll wait</button>
+        </template>
+        <template v-else>
+          <button
+            class="flex-1 glass-button px-4 py-2 rounded-lg text-sm"
+            @click="openSetupGuide"
+          >Setup Guide</button>
+          <button
+            v-if="lightning.fundingReason.value !== 'failed-payment'"
+            class="flex-1 glass-button glass-button-warning px-4 py-2 rounded-lg text-sm font-medium"
+            @click="openLightningSetup"
+          >Open a channel</button>
+          <button
+            v-else
+            class="flex-1 glass-button px-4 py-2 rounded-lg text-sm"
+            @click="onClose"
+          >Close</button>
+        </template>
      </template>
    </div>
  </BaseModal>
@@ -155,7 +197,12 @@ const nodes: NodeChoice[] = [
 const router = useRouter()

 const modalTitle = computed(() => {
-  if (lightningStatusIs('no-funds')) return 'You need a Lightning channel'
+  if (lightningStatusIs('no-funds')) {
+    if (lightning.fundingReason.value === 'pending') return 'Channel confirming…'
+    if (lightning.fundingReason.value === 'far-side') return 'Balance is on the far side'
+    if (lightning.fundingReason.value === 'failed-payment') return 'Payment couldn\u2019t route'
+    return 'You need a Lightning channel'
+  }
  if (lightningStatusIs('stopped')) return 'Lightning node not running'
  return 'Lightning node required'
 })
@@ -1,6 +1,7 @@
 import { describe, it, expect, beforeEach, vi } from 'vitest'
 import { createPinia, setActivePinia } from 'pinia'
 import { useLightningRequired } from '../useLightningRequired'
+import { rpcClient } from '@/api/rpc-client'

 // The gate reads install state off the app store's package list. Stub the
 // store rather than the RPC layer so the test pins the decision, not the
@@ -14,6 +15,12 @@ vi.mock('@/stores/app', () => ({
  }),
 }))

+vi.mock('@/api/rpc-client', () => ({
+  rpcClient: {
+    call: vi.fn(),
+  },
+}))
+
 describe('useLightningRequired', () => {
  beforeEach(() => {
    setActivePinia(createPinia())
@@ -73,4 +80,82 @@ describe('useLightningRequired', () => {
    packages.value = {}
    expect(useLightningRequired().lightningStatus()).toBe('absent')
  })
+
+  describe('requireLightningReady states the node\u2019s real funding state', () => {
+    beforeEach(() => {
+      packages.value = { lnd: { state: 'running' } }
+      vi.mocked(rpcClient.call).mockReset()
+    })
+
+    it('says the channel is confirming, not \u201cno channel\u201d, while pending', async () => {
+      // The regression (framework-pt, 2026-09-01): a just-opened channel
+      // sits in LND's pending list; the outbound sum is legitimately 0, but
+      // the modal claimed the node had no channel at all.
+      vi.mocked(rpcClient.call).mockResolvedValue({
+        total_inbound: 0,
+        total_outbound: 0,
+        channels: [{ status: 'pending_open', local_balance: 900000, remote_balance: 0 }],
+      })
+      const lightning = useLightningRequired()
+
+      expect(await lightning.requireLightningReady('send')).toBe(false)
+      expect(lightning.show.value).toBe(true)
+      expect(lightning.status.value).toBe('no-funds')
+      expect(lightning.fundingReason.value).toBe('pending')
+    })
+
+    it('says the balance is on the far side when channels exist but outbound is 0', async () => {
+      vi.mocked(rpcClient.call).mockResolvedValue({
+        total_inbound: 985000,
+        total_outbound: 0,
+        channels: [{ status: 'active', local_balance: 0, remote_balance: 985000 }],
+      })
+      const lightning = useLightningRequired()
+
+      expect(await lightning.requireLightningReady('send')).toBe(false)
+      expect(lightning.fundingReason.value).toBe('far-side')
+      // The same node CAN receive — the gate must pass for the other way.
+      vi.mocked(rpcClient.call).mockResolvedValue({
+        total_inbound: 985000,
+        total_outbound: 0,
+        channels: [{ status: 'active', local_balance: 0, remote_balance: 985000 }],
+      })
+      expect(await lightning.requireLightningReady('receive')).toBe(true)
+    })
+
+    it('keeps the open-a-channel guidance only when there truly is no channel', async () => {
+      vi.mocked(rpcClient.call).mockResolvedValue({
+        total_inbound: 0,
+        total_outbound: 0,
+        channels: [],
+      })
+      const lightning = useLightningRequired()
+
+      expect(await lightning.requireLightningReady('send')).toBe(false)
+      expect(lightning.fundingReason.value).toBe('none')
+    })
+
+    it('fails OPEN on an RPC error \u2014 a transient blip must not block a working wallet', async () => {
+      vi.mocked(rpcClient.call).mockRejectedValue(new Error('Failed to fetch'))
+      const lightning = useLightningRequired()
+
+      expect(await lightning.requireLightningReady('send')).toBe(true)
+      expect(lightning.show.value).toBe(false)
+    })
+
+    it('maps a routing/liquidity payment failure onto the modal without claiming \u201cno channel\u201d', () => {
+      const lightning = useLightningRequired()
+
+      expect(lightning.handleLightningFailure(new Error('Payment failed: unable to find a path to destination'))).toBe(true)
+      expect(lightning.status.value).toBe('no-funds')
+      expect(lightning.fundingReason.value).toBe('failed-payment')
+    })
+
+    it('leaves non-funding payment errors to the caller', () => {
+      const lightning = useLightningRequired()
+
+      expect(lightning.handleLightningFailure(new Error('Payment failed: Not Found'))).toBe(false)
+      expect(lightning.show.value).toBe(false)
+    })
+  })
 })
@@ -34,12 +34,27 @@ export const LIGHTNING_NODE_APP_IDS = ['lnd'] as const
 *  `running` — good to go. */
 export type LightningStatus = 'absent' | 'stopped' | 'running' | 'no-funds'

+/** WHY the funding modal opened — the old copy always said "you have no
+ *  channel yet", which was a lie three ways: a just-opened channel sits in
+ *  LND's pending list (invisible to the outbound sum) until it has ~3
+ *  confirmations, channels can exist with all their balance on the far
+ *  side, and a payment failure can look like a funding problem. The user
+ *  sees "no channel" while looking at a wallet full of pending liquidity
+ *  (framework-pt, 2026-09-01: "LND thinks I do not have a channel").
+ *  `none` — genuinely no channels, the open-one flow is right.
+ *  `pending` — channel(s) exist but are still confirming on-chain.
+ *  `far-side` — open channel(s), but the needed direction has zero balance.
+ *  `failed-payment` — LND refused a payment; looks like routing/liquidity. */
+export type FundingReason = 'none' | 'pending' | 'far-side' | 'failed-payment'
+
 // Module-scope: one source of truth shared by every caller and the single
 // global modal mounted in App.vue.
 const show = ref(false)
 const status = ref<LightningStatus>('absent')
 /** Which direction raised the funding modal, so the copy can be specific. */
 const fundingDirection = ref<'send' | 'receive'>('receive')
+/** Why the funding modal opened, so the copy states the node's real state. */
+const fundingReason = ref<FundingReason>('none')

 export function useLightningRequired() {
  // The store is resolved lazily, inside the functions that need it, rather
@@ -86,8 +101,9 @@ export function useLightningRequired() {
   * rather than inventing a second one, and routes to the Lightning setup
   * goal where funding and channel-opening already live.
   */
-  function openLightningFunding() {
+  function openLightningFunding(reason: FundingReason = 'none') {
    status.value = 'no-funds'
+    fundingReason.value = reason
    show.value = true
  }

@@ -114,7 +130,9 @@ export function useLightningRequired() {
      'no path',
    ].some((needle) => msg.includes(needle))
    if (!fundingRelated) return false
-    openLightningFunding()
+    // LND refused the payment itself — not necessarily "no channels", so
+    // the modal must not claim it is. Most often this is routing/liquidity.
+    openLightningFunding('failed-payment')
    return true
  }

@@ -133,14 +151,28 @@ export function useLightningRequired() {
  async function requireLightningReady(direction: 'send' | 'receive'): Promise<boolean> {
    if (!requireLightningNode()) return false
    try {
-      const res = await rpcClient.call<{ total_inbound?: number; total_outbound?: number }>({
+      const res = await rpcClient.call<{
+        total_inbound?: number
+        total_outbound?: number
+        channels?: { status?: string; local_balance?: number; remote_balance?: number }[]
+      }>({
        method: 'lnd.listchannels',
        timeout: 15000,
      })
      const liquidity = direction === 'receive' ? res?.total_inbound ?? 0 : res?.total_outbound ?? 0
      if (liquidity > 0) return true
      fundingDirection.value = direction
-      openLightningFunding()
+      // Zero in the needed direction — say WHY, from the same response.
+      // The channel list carries pending entries (status 'pending_open');
+      // the totals deliberately exclude them (nothing is spendable through
+      // an unconfirmed channel), so "0 outbound + pending channels" is the
+      // just-opened-a-channel state, not "no channel".
+      const channels = res?.channels ?? []
+      const hasPending = channels.some(c => c.status === 'pending_open')
+      const hasOpen = channels.some(
+        c => c.status === 'active' || c.status === 'inactive' || (!c.status && (c.local_balance || c.remote_balance)),
+      )
+      openLightningFunding(hasPending ? 'pending' : hasOpen ? 'far-side' : 'none')
      return false
    } catch {
      return true
@@ -150,6 +182,7 @@ export function useLightningRequired() {
  return {
    show,
    fundingDirection,
+    fundingReason,
    status,
    lightningStatus,
    hasLightningNode,
@@ -115,6 +115,24 @@ const showConnectForm = ref(false)
 const connecting = ref(false)
 const connectedParams = ref<Record<string, string> | null>(null)

+// Every action below (install/edit TollGate, WiFi scan, WAN configure) needs
+// host/ssh_user/ssh_password to reach the router. `connectedParams` only gets
+// set when the Connect form was actually submitted this session (WR-03 above)
+// — on a normal page load the router reconnects via the server-persisted
+// config instead, so `sshPassword`/`sshUser`/`host` (the Connect form's own
+// local refs) sit at their untouched defaults ('', 'root', ''). Falling back
+// to those refs here used to send an explicit-but-empty ssh_password, which
+// the backend treats as "the caller provided this" and never falls back to
+// the real saved password — a real router password then fails auth on every
+// action even though the status poll (which sends no params at all) keeps
+// working fine (archy-x250-pa3, 2026-09-05: dropbear logged one bad-password
+// attempt at the exact moment "Install TollGate" was clicked). Omitting the
+// fields entirely when there's no explicit connectedParams lets the backend's
+// own saved-config fallback do the right thing, same as the status poll.
+function authParams(): Record<string, string> {
+  return connectedParams.value ?? {}
+}
+
 const detecting = ref(false)
 const detectError = ref('')
 const detectedCandidates = ref<string[]>([])
@@ -271,11 +289,7 @@ async function provisionTollgate() {
  provisionError.value = ''
  provisionSuccess.value = false
  try {
-    const params: Record<string, unknown> = {
-      host: connectedParams.value?.host ?? status.value?.host,
-      ssh_user: connectedParams.value?.ssh_user ?? sshUser.value,
-      ssh_password: connectedParams.value?.ssh_password ?? sshPassword.value,
-    }
+    const params: Record<string, unknown> = { ...authParams() }
    await rpcClient.call({ method: 'openwrt.provision-tollgate', params, timeout: 300000 })
    provisionSuccess.value = true
    await load(connectedParams.value ?? undefined)
@@ -302,9 +316,7 @@ async function saveTollgateConfig() {
  updateTollgateError.value = ''
  try {
    const params: Record<string, unknown> = {
-      host: connectedParams.value?.host ?? status.value?.host,
-      ssh_user: connectedParams.value?.ssh_user ?? sshUser.value,
-      ssh_password: connectedParams.value?.ssh_password ?? sshPassword.value,
+      ...authParams(),
      price_sats: editPriceSats.value,
      step_size_ms: editStepSizeMin.value * 60_000,
      min_steps: editMinSteps.value,
@@ -336,11 +348,7 @@ async function scanWifi() {
  wanStep.value = 'scanning'
  wanError.value = ''
  try {
-    const params: Record<string, unknown> = {
-      host: connectedParams.value?.host ?? status.value?.host,
-      ssh_user: connectedParams.value?.ssh_user ?? sshUser.value,
-      ssh_password: connectedParams.value?.ssh_password ?? sshPassword.value,
-    }
+    const params: Record<string, unknown> = { ...authParams() }
    const result = await rpcClient.call<{ networks: ScannedNetwork[] }>({
      method: 'openwrt.scan-wifi',
      params,
@@ -367,9 +375,7 @@ async function configureWan() {
  wanError.value = ''
  try {
    const params: Record<string, unknown> = {
-      host: connectedParams.value?.host ?? status.value?.host,
-      ssh_user: connectedParams.value?.ssh_user ?? sshUser.value,
-      ssh_password: connectedParams.value?.ssh_password ?? sshPassword.value,
+      ...authParams(),
      ssid: selectedNetwork.value.ssid,
      password: wanPassword.value,
      encryption: selectedNetwork.value.encryption,
@@ -362,6 +362,18 @@ init()
              </button>
            </div>
            <div class="overflow-y-auto flex-1 min-h-0 space-y-6 pr-1">
+              <!-- v1.8.10-alpha -->
+              <div>
+                <div class="flex items-center gap-2 mb-3">
+                  <span class="text-xs font-mono px-2 py-0.5 rounded bg-orange-500/20 text-orange-300">v1.8.10-alpha</span>
+                  <span class="text-xs text-white/40">September 2, 2026</span>
+                </div>
+                <div class="space-y-3 text-sm text-white/80 pl-3 border-l border-white/10">
+                  <p><strong>Lightning sends work again.</strong> v1.8.9's move to LND 0.21's supported payment route shipped without a fee budget, and the API treats a missing one as zero allowed fees — so every wallet send failed "No route to the recipient" all day, on perfectly healthy channels. Payments now carry a proper fee budget and a test keeps it from ever regressing.</p>
+                  <p><strong>A channel that drops its peer link now heals itself — on every node.</strong> Restarting LND (an app update, a reboot, container churn) can leave a channel's peer connection down for hours while both endpoints keep the channel flagged disabled in the routing graph: the node looks perfectly healthy, the wallet shows balance, and every payment in either direction fails "no route to the recipient". The daemon now watches the channel graph as desired state — every open channel should have a live peer — and reconnects any that don't. Nodes without LND are untouched; an unreachable peer is retried gently.</p>
+                  <p><strong>The Lightning wallet says what's actually wrong, instead of "you have no channel".</strong> Trying to send while a channel you just opened was still confirming — or when all its balance sits on the far side — produced a modal claiming you had no channel at all, and payment routing failures even showed the receiving copy. The gate now reads your real channel list: a confirming channel gets "it unlocks automatically once confirmed, nothing is needed from you", a far-side balance gets "you can receive, but there's nothing to send right now", and only a genuinely channel-less node is sent to open one.</p>
+                </div>
+              </div>
              <!-- v1.8.9-alpha -->
              <div>
                <div class="flex items-center gap-2 mb-3">
@@ -374,6 +386,7 @@ init()
                  <p><strong>Apps open over HTTPS again, including Mempool, Bitcoin and IndeeHub.</strong> The launcher looked each app's port policy up in the signed catalog under the name you click, but the catalog lists that port under the app that owns it — so Mempool "did not connect", Bitcoin opened a plain-http tab, and Nostr sign-in on IndeeHub silently did nothing over HTTPS. Launches now follow the alias to the owning manifest, the catalog is loaded before the first app you open (not just in the App Store), and the Nostr bridge replies to the app frame's real origin instead of a stale recorded address.</p>
                  <p><strong>Nginx Proxy Manager starts again.</strong> Its manifest was missing two things its image requires — the LetsEncrypt folder mount and the permission to bind low ports — leaving it in an endless restart loop on nodes that had it installed. Both are declared now; your existing certificates are untouched, and the fix arrives via the signed catalog without waiting for this release.</p>
                  <p><strong>Portainer's first-run token is on the app page, not buried in "server logs".</strong> New Portainer versions hand the first admin a one-time setup token that was only printed in the container logs — on this box, that token now appears with your app's other credentials, with a copy button, and disappears once setup is done.</p>
+                  <p><strong>The Lightning wallet says what's actually wrong, instead of "you have no channel".</strong> Trying to send while a channel you just opened was still confirming — or when all its balance sits on the far side — produced a modal claiming you had no channel at all. The gate now looks at your real channel list: a confirming channel gets "it unlocks automatically once confirmed, nothing needed from you", a far-side balance gets "you can receive but there's nothing to send right now", and only a genuinely channel-less node is sent to open one.</p>
                </div>
              </div>
              <!-- v1.8.8-alpha -->
@@ -1,30 +1,29 @@
 {
  "changelog": [
-    "**SSH over the mesh is now a first-class setting.** Settings gains an \"SSH over mesh\" card: off by default, and when you allow it the node's mesh firewall opens port 22 — either to every mesh peer (behind an explicit \"I understand\" confirmation, because that's a real exposure) or only to the mesh addresses you list. The rule is owned by the node (the `90-ssh.nft` drop-in), so it survives upgrades and daemon reinstalls, and the card tells you up front whether sshd is running, whether it listens on IPv6 (the mesh is IPv6-only — this is what a broken attempt looks like before it happens), and whether password login is on (keys-only is the recommended pairing). From Termux on your phone, `fipssh <user>@<node-npub>` connects once the toggle is on — the npub is the durable address, and the command is shown with a copy button on the card.",
-    "**The App Store now lists apps — not parts of apps.** The signed catalog carries every manifest because the node's update layer needs their pins, and the store briefly listed them all: Mempool API, LND UI, Bitcoin UI, the Pine voice engines, the IndeeHub and Immich backends, the mesh router and friends. Components are hidden from the store listing (they still appear where they belong — the Services tab of My Apps, once installed), and four entries that never earned a tile are gone outright: MorphOS server (old), the Web5 DID wallet, Lightning Stack (an untracked upstream bundle — LND covers the need), and CryptPad (never tested).",
-    "**App icons now persist everywhere, in the proper container style.** Two fixes: installed apps render the icon from their own manifest — Cuprate no longer falls back to the generic A-mark on its Services tile — and the store grids (the Discover page) apply the same icon container treatment (backdrop, border, shadow) as My Apps, the detail pages, and Home. Manifest-declared UI apps also classify correctly again: Alby Hub installs into My Apps with a working tile, not into Services, because a probe miss no longer buries an app the manifest itself says has a frontend.",
-    "**Installing from the store keeps you on the store page.** The install progress lives on the tile itself and the app appears in My Apps when it lands — no more being yanked to My Apps mid-browse."
+    "**Lightning sends work again — v1.8.9's payment switch lost the fee budget.** Moving payments to LND 0.21's supported route (Router.SendPaymentV2) shipped without a fee limit, and the v2 API treats an absent limit as **zero allowed fees**: every real route carries a routing fee, so the pathfinder rejected them all and the wallet answered \"No route to the recipient\" on every send — all day, on healthy channels with plenty of liquidity. The router debug log made it unambiguous (`fee_limit=0 mSAT` on every failing wallet payment; the same payment succeeded by hand the moment a fee limit was set). Payments now carry lncli's default budget (the payment amount), the wallet's amount handling for zero-value invoices is preserved, and a unit test pins the limit can never be zero again.",
+    "**A channel that drops its peer link now heals itself — on every node.** Restarting LND (an app update, a reboot, container churn) can leave a channel's peer connection down for hours while both endpoints keep the channel flagged disabled in the routing graph: the node looks perfectly healthy, the wallet shows balance, and every payment in either direction fails \"no route to the recipient\". Observed live: a node's only channel sat unroutable for ~17 hours after the LND 0.21.2 update, with no sign of it in any dashboard. The daemon now watches the channel graph as desired state — every open channel should have a live peer — and reconnects any that don't, using the peer's advertised addresses. Nodes without LND are untouched; an unreachable peer is retried gently, not hammered.",
+    "**The Lightning wallet states the node's real funding state instead of \"you have no channel.\"** Trying to send while a freshly opened channel was still waiting for on-chain confirmations — or when all its balance sits on the far side — raised a modal that claimed the node had NO channel at all (the outbound sum is legitimately zero in both states), pointed the user at opening a second channel, and — for payment routing failures — even showed the *receiving* copy. The funding gate now reads the channel list it already fetched: a confirming channel gets \"it unlocks automatically once confirmed, nothing is needed from you\", a far-side balance gets \"you can receive, but there's nothing to send right now\", a routing/liquidity payment failure says so instead of claiming channel problems, and only a genuinely channel-less node keeps the open-one guidance."
  ],
  "components": [
    {
-      "current_version": "1.8.8-alpha",
-      "download_url": "https://source.archipelago-foundation.org/lfg2025/archy/releases/download/v1.8.8-alpha/archipelago",
+      "current_version": "1.8.10-alpha",
+      "download_url": "https://source.archipelago-foundation.org/lfg2025/archy/releases/download/v1.8.10-alpha/archipelago",
      "name": "archipelago",
-      "new_version": "1.8.8-alpha",
-      "sha256": "96f39b8db6f08386200e1eab91c8444a7758526e6034100c8a33907ff9263530",
-      "size_bytes": 64175864
+      "new_version": "1.8.10-alpha",
+      "sha256": "6c8bd41fed44cd999cb360c00e1b66a2d19d19812cc2b0c8a1677eec2a9579e6",
+      "size_bytes": 64178056
    },
    {
-      "current_version": "1.8.8-alpha",
-      "download_url": "https://source.archipelago-foundation.org/lfg2025/archy/releases/download/v1.8.8-alpha/archipelago-frontend-1.8.8-alpha.tar.gz",
-      "name": "archipelago-frontend-1.8.8-alpha.tar.gz",
-      "new_version": "1.8.8-alpha",
-      "sha256": "7829b67edf8dec27997dd821650ed4d61aea721f802d46a8d47014f4b4246db1",
-      "size_bytes": 97730549
+      "current_version": "1.8.10-alpha",
+      "download_url": "https://source.archipelago-foundation.org/lfg2025/archy/releases/download/v1.8.10-alpha/archipelago-frontend-1.8.10-alpha.tar.gz",
+      "name": "archipelago-frontend-1.8.10-alpha.tar.gz",
+      "new_version": "1.8.10-alpha",
+      "sha256": "6b25de8a8e1a4f7fe51594f9bbbe21f5820f417af47a8b309c2dbf8f8723b719",
+      "size_bytes": 97736297
    }
  ],
  "release_date": "2026-09-01",
-  "signature": "c839cbdcb356a503d87bc17f52b6e5f3a934ae1e72a891f2d21d85366f23debb224a2a40b9124bab50fe95444e01e27711690b1bc50062f40b7ed4f34e078d06",
+  "signature": "b69926bcb1851ff7d6a5b24519cd4a8015aab4ed4b588ee989d8ce6e3beaeb2cc0eb38078f522ded0d389fe53b7dbcdbf3f40c534b4bfafa5cf4a2ab2c59e40f",
  "signed_by": "did:key:z6Mkfu5LT8d4DjETtrkATvHh9Dvcbnr7zBCUwfau8Sw7DLWT",
-  "version": "1.8.8-alpha"
+  "version": "1.8.10-alpha"
 }
@@ -1,30 +1,29 @@
 {
  "changelog": [
-    "**SSH over the mesh is now a first-class setting.** Settings gains an \"SSH over mesh\" card: off by default, and when you allow it the node's mesh firewall opens port 22 — either to every mesh peer (behind an explicit \"I understand\" confirmation, because that's a real exposure) or only to the mesh addresses you list. The rule is owned by the node (the `90-ssh.nft` drop-in), so it survives upgrades and daemon reinstalls, and the card tells you up front whether sshd is running, whether it listens on IPv6 (the mesh is IPv6-only — this is what a broken attempt looks like before it happens), and whether password login is on (keys-only is the recommended pairing). From Termux on your phone, `fipssh <user>@<node-npub>` connects once the toggle is on — the npub is the durable address, and the command is shown with a copy button on the card.",
-    "**The App Store now lists apps — not parts of apps.** The signed catalog carries every manifest because the node's update layer needs their pins, and the store briefly listed them all: Mempool API, LND UI, Bitcoin UI, the Pine voice engines, the IndeeHub and Immich backends, the mesh router and friends. Components are hidden from the store listing (they still appear where they belong — the Services tab of My Apps, once installed), and four entries that never earned a tile are gone outright: MorphOS server (old), the Web5 DID wallet, Lightning Stack (an untracked upstream bundle — LND covers the need), and CryptPad (never tested).",
-    "**App icons now persist everywhere, in the proper container style.** Two fixes: installed apps render the icon from their own manifest — Cuprate no longer falls back to the generic A-mark on its Services tile — and the store grids (the Discover page) apply the same icon container treatment (backdrop, border, shadow) as My Apps, the detail pages, and Home. Manifest-declared UI apps also classify correctly again: Alby Hub installs into My Apps with a working tile, not into Services, because a probe miss no longer buries an app the manifest itself says has a frontend.",
-    "**Installing from the store keeps you on the store page.** The install progress lives on the tile itself and the app appears in My Apps when it lands — no more being yanked to My Apps mid-browse."
+    "**Lightning sends work again — v1.8.9's payment switch lost the fee budget.** Moving payments to LND 0.21's supported route (Router.SendPaymentV2) shipped without a fee limit, and the v2 API treats an absent limit as **zero allowed fees**: every real route carries a routing fee, so the pathfinder rejected them all and the wallet answered \"No route to the recipient\" on every send — all day, on healthy channels with plenty of liquidity. The router debug log made it unambiguous (`fee_limit=0 mSAT` on every failing wallet payment; the same payment succeeded by hand the moment a fee limit was set). Payments now carry lncli's default budget (the payment amount), the wallet's amount handling for zero-value invoices is preserved, and a unit test pins the limit can never be zero again.",
+    "**A channel that drops its peer link now heals itself — on every node.** Restarting LND (an app update, a reboot, container churn) can leave a channel's peer connection down for hours while both endpoints keep the channel flagged disabled in the routing graph: the node looks perfectly healthy, the wallet shows balance, and every payment in either direction fails \"no route to the recipient\". Observed live: a node's only channel sat unroutable for ~17 hours after the LND 0.21.2 update, with no sign of it in any dashboard. The daemon now watches the channel graph as desired state — every open channel should have a live peer — and reconnects any that don't, using the peer's advertised addresses. Nodes without LND are untouched; an unreachable peer is retried gently, not hammered.",
+    "**The Lightning wallet states the node's real funding state instead of \"you have no channel.\"** Trying to send while a freshly opened channel was still waiting for on-chain confirmations — or when all its balance sits on the far side — raised a modal that claimed the node had NO channel at all (the outbound sum is legitimately zero in both states), pointed the user at opening a second channel, and — for payment routing failures — even showed the *receiving* copy. The funding gate now reads the channel list it already fetched: a confirming channel gets \"it unlocks automatically once confirmed, nothing is needed from you\", a far-side balance gets \"you can receive, but there's nothing to send right now\", a routing/liquidity payment failure says so instead of claiming channel problems, and only a genuinely channel-less node keeps the open-one guidance."
  ],
  "components": [
    {
-      "current_version": "1.8.8-alpha",
-      "download_url": "https://source.archipelago-foundation.org/lfg2025/archy/releases/download/v1.8.8-alpha/archipelago",
+      "current_version": "1.8.10-alpha",
+      "download_url": "https://source.archipelago-foundation.org/lfg2025/archy/releases/download/v1.8.10-alpha/archipelago",
      "name": "archipelago",
-      "new_version": "1.8.8-alpha",
-      "sha256": "96f39b8db6f08386200e1eab91c8444a7758526e6034100c8a33907ff9263530",
-      "size_bytes": 64175864
+      "new_version": "1.8.10-alpha",
+      "sha256": "6c8bd41fed44cd999cb360c00e1b66a2d19d19812cc2b0c8a1677eec2a9579e6",
+      "size_bytes": 64178056
    },
    {
-      "current_version": "1.8.8-alpha",
-      "download_url": "https://source.archipelago-foundation.org/lfg2025/archy/releases/download/v1.8.8-alpha/archipelago-frontend-1.8.8-alpha.tar.gz",
-      "name": "archipelago-frontend-1.8.8-alpha.tar.gz",
-      "new_version": "1.8.8-alpha",
-      "sha256": "7829b67edf8dec27997dd821650ed4d61aea721f802d46a8d47014f4b4246db1",
-      "size_bytes": 97730549
+      "current_version": "1.8.10-alpha",
+      "download_url": "https://source.archipelago-foundation.org/lfg2025/archy/releases/download/v1.8.10-alpha/archipelago-frontend-1.8.10-alpha.tar.gz",
+      "name": "archipelago-frontend-1.8.10-alpha.tar.gz",
+      "new_version": "1.8.10-alpha",
+      "sha256": "6b25de8a8e1a4f7fe51594f9bbbe21f5820f417af47a8b309c2dbf8f8723b719",
+      "size_bytes": 97736297
    }
  ],
  "release_date": "2026-09-01",
-  "signature": "c839cbdcb356a503d87bc17f52b6e5f3a934ae1e72a891f2d21d85366f23debb224a2a40b9124bab50fe95444e01e27711690b1bc50062f40b7ed4f34e078d06",
+  "signature": "b69926bcb1851ff7d6a5b24519cd4a8015aab4ed4b588ee989d8ce6e3beaeb2cc0eb38078f522ded0d389fe53b7dbcdbf3f40c534b4bfafa5cf4a2ab2c59e40f",
  "signed_by": "did:key:z6Mkfu5LT8d4DjETtrkATvHh9Dvcbnr7zBCUwfau8Sw7DLWT",
-  "version": "1.8.8-alpha"
+  "version": "1.8.10-alpha"
 }
@@ -1,32 +0,0 @@
-{
-  "changelog": [
-    "**Lightning sends work again after the LND 0.21.2 update.** LND 0.21 removed the old synchronous payment route the node's backend paid through (`/v1/channels/transactions`) — every Lightning send answered the literal \"Not Found\" and the wallet showed \"Payment failed: Not Found\". The backend now pays through the supported Router.SendPaymentV2 route, keeps the same settle-then-report behaviour (a slow multi-hop payment is still tracked to completion, never falsely declared failed), and translates LND's failure reasons into plain advice. A new gate test speaks the payment route directly against the running LND, so an image/backend skew like this can never ship silently again.",
-    "**The node no longer pins HSTS — HTTP access is a supported mode, and it stays working.** The HTTPS listener used to send `Strict-Transport-Security: max-age=31536000; includeSubDomains`; browsers that visited HTTPS once cached that and then silently upgraded the still-open HTTP dashboard's calls to HTTPS, which is a scheme change — cross-origin — so every request died as \"CORS blocked / Failed to fetch\" while the node was perfectly healthy. The HTTPS listener now actively clears the cached policy (`max-age=0`) and port 80 sends no HSTS at all, which is deliberate: the node's certificate is optional and self-signed, and devices that haven't installed the CA must keep plain-HTTP access (that's what Settings → Node certificate is for). If your browser already cached the old policy, visiting the dashboard over HTTPS once after this update clears it; a gate test now refuses any config that reintroduces the pin.",
-    "**App frames open over HTTPS again — including the ones that \"did not connect.\"** The launcher asked the signed catalog for each app's port policy under the name you click (\"Mempool Web\", \"Bitcoin Knots\"), but the catalog declares those ports under the manifest that owns them (the Mempool web container, Bitcoin UI). The lookup missed, the launcher handed the iframe an `http://` address, and the browser blocked it as mixed content — the app tile went blank or spun forever. Port resolution now follows launch aliases (mempool-web, bitcoin-knots/bitcoin-core, lnd, electrs and friends), falls back to a port-wide catalog scan when the id is unknown, and the catalog is warmed as soon as the dashboard loads rather than only in the App Store, so the very first app you open already knows which ports serve TLS.",
-    "**Signing in to IndeeHub with Nostr works over HTTPS.** The NIP-07 bridge compared the app frame's origin for exact equality with the recorded `http://` app URL — a frame the browser upgraded to HTTPS (or any scheme change) was silently ignored, and replies addressed to the stale origin were refused outright, so Nostr sign-in quietly did nothing. The bridge now matches host and port (scheme intentionally ignored) and always replies to the frame's real origin.",
-    "**Nginx Proxy Manager starts again.** Converting it to a platform manifest dropped two things its image needs: the `/etc/letsencrypt` mount its boot script hard-requires, and the `NET_BIND_SERVICE` capability its internal nginx needs to bind ports 80/443/81 under the orchestrator's `--cap-drop=ALL`. The result was an endless start/die loop (a node watched it restart 3,176 times). Both are declared in its manifest now, its certs live on unchanged under the same persistent app directory, and the signed catalog carries the fix so installed nodes heal on the next update.",
-    "**Portainer's first-run token is in the app page, not buried in \"server logs.\"** New Portainer versions mint a one-time setup token on a fresh install and print it only to the container logs — on an appliance that meant telling the user to go read a server log to get into their own app. The token now appears in the same launch interstitial as app login credentials (with a copy button), only while first-run setup is actually pending; once the admin account exists the card disappears on its own."
-  ],
-  "components": [
-    {
-      "current_version": "1.8.9-alpha",
-      "download_url": "https://source.archipelago-foundation.org/lfg2025/archy/releases/download/v1.8.9-alpha/archipelago",
-      "name": "archipelago",
-      "new_version": "1.8.9-alpha",
-      "sha256": "39795958963680f56763e3c05e3fe0cd589c30edd9a09416ad325bab4c862123",
-      "size_bytes": 64139152
-    },
-    {
-      "current_version": "1.8.9-alpha",
-      "download_url": "https://source.archipelago-foundation.org/lfg2025/archy/releases/download/v1.8.9-alpha/archipelago-frontend-1.8.9-alpha.tar.gz",
-      "name": "archipelago-frontend-1.8.9-alpha.tar.gz",
-      "new_version": "1.8.9-alpha",
-      "sha256": "624dd10dfea09809be1fdddc7eac804e1fde66ff3d552cb90d56d9ac550ed944",
-      "size_bytes": 97734650
-    }
-  ],
-  "release_date": "2026-09-01",
-  "signature": "d7d724b910e827651240bd9520102d66932b57a8a8d674ef645c45eb77f78c123fb45d294ec07f8bbfc3713ed9bd9f98096f59ff18cd6098df51aa473e771908",
-  "signed_by": "did:key:z6Mkfu5LT8d4DjETtrkATvHh9Dvcbnr7zBCUwfau8Sw7DLWT",
-  "version": "1.8.9-alpha"
-}
Author	SHA1	Message	Date
ssmithxandClaude Sonnet 5	094f42312c	docs(openwrt): document the confirmed working end-to-end install flow Adds a verification checklist (service running, nodogsplash bound to br-tollgate not br-lan via the rendered config not just UCI, LAN/SSH untouched, mint probes succeeding) plus notes on the dev-build test-mint injection and the default-route race between a router's LAN interface and the node's other uplinks before the router's own WAN/WISP is live. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0176RpCxFNS9ZaSJjL72W9Z5	2026-09-07 03:06:58 +00:00
ssmithxandClaude Sonnet 5	da8c3ec193	docs(openwrt): note the Ctrl+T/LuCI workaround for setting the initial root password Archipelago's Connect form only authenticates with an existing password; it has no flow for setting one on a fresh, passwordless router. On the node's kiosk display there's no visible tab bar, so Ctrl+T to open a new tab to LuCI is the way to set it before Connect will work. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0176RpCxFNS9ZaSJjL72W9Z5	2026-09-07 02:53:21 +00:00
ssmithxandClaude Sonnet 5	4fdf8e8c58	fix(openwrt): bump pinned TollGate release v0.2.0 -> v0.5.0 The install code was hardcoded to the Oct 2025 v0.2.0 release — nine releases behind. Its changelog covers exactly the failures hit live against archy-x250-pa3: a mint with an empty/broken keyset crash-looped tollgate-wrt forever (v0.5.0 adds "graceful degradation when Cashu mints fail"), and the bundled captive-portal JS had zero CBOR support, hard-rejecting the cashuB (NUT-00 V4) tokens modern wallets like Minibits generate by default. Also: v0.5.0 publishes native .apk packages for aarch64_cortex-a53 and x86_64. install_tollgate_apk_native now prefers those directly (apk add handles deps/postinst/uci-defaults itself) instead of always falling back to the manual ar/tar .ipk extraction dance, which only exists because earlier releases had no native apk build at all. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0176RpCxFNS9ZaSJjL72W9Z5	2026-09-05 17:28:20 +00:00
ssmithxandClaude Sonnet 5	61b5d93b11	docs(openwrt): document the transient post-reboot apk-update failure Observed live on archy-x250-pa3: right after WAN reconnects (fresh boot or WAN reconfigure), the first Install attempt can fail with "apk update failed ... router may have no internet access" purely because the WiFi-uplink STA association hasn't finished yet — it's not a real error, just retry a few seconds later. Also cross-referenced the now-fixed /usr/bin/opkg hardcoding bug for anyone hitting it on an older build. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0176RpCxFNS9ZaSJjL72W9Z5	2026-09-05 16:36:53 +00:00
ssmithxandClaude Sonnet 5	be06b3ce2b	fix(ui): stop sending an empty ssh_password over the saved router connection provisionTollgate/saveTollgateConfig/scanWifi/configureWan all fell back to the Connect form's local refs (host/sshUser/sshPassword) when connectedParams was null. Those refs only get populated if the form was actually submitted this session — on a normal page load the router reconnects via the server-persisted config instead, leaving sshPassword at its default ''. Sending that as an explicit (empty-but-present) ssh_password overrides the backend's saved-config fallback, so every action auths with a blank password instead of the real saved one. Added authParams(): omit host/ssh_user/ssh_password entirely unless connectedParams is actually set, same as the status poll already does. Caught live: dropbear on archy-x250-pa3's router logged a single bad password attempt at the exact moment "Install TollGate" was clicked, sandwiched between periodic status-poll connections succeeding with the real saved password. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0176RpCxFNS9ZaSJjL72W9Z5	2026-09-05 15:14:07 +00:00
ssmithxandClaude Sonnet 5	f3d96ae2ee	fix(openwrt): resolve opkg/apk via $PATH, not a hardcoded /usr/bin path opkg_check() and every opkg/apk invocation hardcoded /usr/bin/opkg and /usr/bin/apk. Official OpenWrt images don't all symlink /bin into /usr/bin — the glinet_gl-mt3000 24.10.2 build keeps them as separate real directories with opkg living in /bin — so the check silently missed a perfectly normal install and TollGate provisioning failed with "this router's firmware may not support package management". Switched every call to resolve through the router's own $PATH (command -v / bare opkg / apk) instead. Reproduced and fixed live against archy-x250-pa3, 2026-09-05. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0176RpCxFNS9ZaSJjL72W9Z5	2026-09-05 15:14:00 +00:00
ssmithxandClaude Sonnet 5	a4ae375617	docs(openwrt): fix TollGate step — install is separate from configure Step 4 described a single "Provision TollGate" action that prompts for price/step/mint upfront. The real UI (OpenWrtGateway.vue) doesn't work that way: "Install TollGate" is a one-click action with no config form that installs with defaults, and price/step/mint/enabled are only editable afterward via a separate "Edit" panel. Caught while walking through a live install. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0176RpCxFNS9ZaSJjL72W9Z5	2026-09-05 14:32:39 +00:00
ssmithxandClaude Sonnet 5	0646bc4e85	docs(openwrt): add GL.iNet AX3000 → stock OpenWrt flashing steps Worked example for the Beryl AX (GL-MT3000, mediatek/filogic) verified against the OpenWrt wiki and firmware selector: exact sysupgrade image filename, GL.iNet UI / LuCI flash path, post-flash SSH state, and the U-Boot recovery procedure if the flash goes sideways. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0176RpCxFNS9ZaSJjL72W9Z5	2026-09-05 14:26:21 +00:00
ssmithxandClaude Sonnet 5	0faaf4577f	docs: add OpenWrt Gateway setup guide Walks a node operator through pairing an OpenWrt router over SSH, running the WAN/WISP wizard, and provisioning TollGate pay-as-you-go WiFi — plus an RPC/architecture reference for developers. Distills the openwrt crate, RPC handlers, and Vue panel into user-facing steps that didn't exist anywhere in docs/ before. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0176RpCxFNS9ZaSJjL72W9Z5	2026-09-05 14:07:05 +00:00
archipelago	d8320896c4	chore: publish release v1.8.10-alpha Demo images / Build & push demo images (push) Successful in 3m26s Details	2026-09-01 19:01:54 -04:00
archipelago	b87f1f0612	chore: prepare release v1.8.10-alpha	2026-09-01 18:58:33 -04:00
archipelago	1ca002661b	fix(lnd): SendPaymentV2 needs an explicit fee budget — absent means ZERO Demo images / Build & push demo images (push) Successful in 3m28s Details v1.8.9's move to Router.SendPaymentV2 shipped without fee_limit_sat, and the v2 route treats an ABSENT fee limit as zero allowed fees. Every real route carries a routing fee (the 2-hop route here: 1.5 sats), so the pathfinder rejected them all and the wallet answered "No route to the recipient" on EVERY send — all day, on healthy channels with plenty of liquidity both ways. The router debug log makes it unambiguous: wallet payment (v1.8.9 backend): fee_limit=0 mSAT -> no route same payment by hand (lncli --fee_limit=100): fee_limit=100000 mSAT -> settles in 0.65s My earlier "pipeline verified" claim was wrong — the manual lncli verification set a fee limit by hand and masked this exact bug. The 400k that succeeded this morning went through the pre-update backend on the pre-update LND. Payments now carry lncli's own default budget — the payment amount (100%), preferring the payer-supplied amount for zero-value invoices and the invoice's own amount otherwise, with a nominal floor so the limit can never be zero. Unit-pinned so it cannot regress.	2026-09-01 18:42:37 -04:00
archipelago	0d0e2e243a	feat(lnd): channel-peer watchdog — a dropped peer link heals itself Demo images / Build & push demo images (push) Successful in 3m49s Details LND normally reconnects channel peers after a restart, but not reliably: after long or repeated downtime (an app update, a node reboot, reconciler churn) the peer link can stay down for hours while BOTH endpoints keep the channel flagged disabled in the routing graph. The node looks perfectly healthy, the wallet shows balance, and every payment in either direction fails "no route to the recipient" — observed live on framework-pt (2026-09-01): its only channel sat disabled on both policy sides for ~17 hours after the LND 0.21.2 update, while shorty had 583k spendable and the user was told, by a mis-mapped modal, that they had 'no payment channel'. The channel graph is desired state — every open channel should have a live peer connection. A daemon-side watchdog now enforces it: - every 2 minutes, list channels + peers over LND REST - for each channel whose remote peer is not connected, look the peer's advertised addresses up in the public graph and dial one - per-peer retries throttled to 10 minutes so an unreachable peer is not hammered; 'already connected' counts as done; a peer with no advertised address is logged once per pass (cannot be dialed) - no-ops quietly on nodes without LND (missing macaroon) and while a wallet is locked (503 body has no channels) Unit tests pin the selection against the live REST shapes (remote_pubkey in /v1/channels vs pub_key in /v1/peers). v1.8.10 CHANGELOG + What's New entries staged so the next release run is clean first time.	2026-09-01 17:51:15 -04:00
archipelago	9c49b502e3	docs: post-1.8.9 verification — pipeline confirmed, routing failure root-caused to framework-pt's disabled channel	2026-09-01 16:36:27 -04:00
archipelago	d68a013e35	docs: tracker — v1.8.9 published, NPM live-healed on shorty via the signed catalog; funding-gate fix staged for v1.8.10	2026-09-01 11:43:33 -04:00
archipelago	1464b1b24d	fix(wallet): the Lightning funding gate states the node's real channel state Demo images / Build & push demo images (push) Successful in 3m38s Details "LND thinks I do not have a channel" while the wallet showed plenty of liquidity (framework-pt, 2026-09-01): the send gate sums outbound over FULLY-OPEN channels only, which is correct — a just-opened channel sits in LND's pending list until it has ~3 confirmations, and an open channel can have all its balance on the far side — but the modal then claimed the node had NO channel at all, in every one of those states, and pointed the user at opening another one. The gate already fetched the full channel list; it now records WHY liquidity is zero and the modal says the truth per state: - pending channels -> "your new channel is waiting for on-chain confirmations, it unlocks automatically, nothing is needed from you" (and no "Open a channel" button — that would send the user to fix a problem they don't have, possibly opening a second channel) - open channels, zero on the needed side -> "balance is on the far side — you can receive but there's nothing to send right now" - payment refused with a routing/liquidity error -> says so, instead of claiming no channels - only a genuinely channel-less node keeps the open-one guidance Eleven unit tests pin the state machine, including the regression case (pending-only -> 'pending', not 'none') and fail-open on RPC errors.	2026-09-01 11:40:25 -04:00
archipelago	82001403b4	chore: publish release v1.8.9-alpha	2026-09-01 11:05:55 -04:00