PnP: "Try again" does not work on "Couldn't establish a connection" page

[kateatlinksys]

Precondition:

1. Factory reset the DUT.
2. DUT has no internet.

Reproduce steps:

1. Login to Linksys Now.
2. Proceed to the "Couldn't establish a connection" page (/pnpNoInternetConnection).
3. Click "Try again".
4. Reconnect the WAN cable and wait until the router LED turns solid white.
5. Click "Try again" again.

Actual result:
"Try again" does not work — clicking it (in step 3 with no internet, and again in step 5 after internet is restored / LED solid white) only shows a brief spinner and always returns to the same error page. The connection is never re-established.

Expected result:
"Try again" should re-check the connection and proceed past the error page once the internet is available.

Env.: Pinnacle 2.0 FW 1.2.2.26062820 / Linksys Now 2.5.0.700525

Log:

GUI_internetfailed_try again failed_0708.txt

Screenshot:

Additional note: The other two recovery flows on this page also fail the same way — after completing the full flow, the app still returns to the "Couldn't establish a connection" page, even though the internet is actually up:

• Restart your modem — complete the flow → back to the error page.
• Enter ISP settings > DHCP — complete the flow → back to the error page.

So all three options (Try again / Restart your modem / Enter ISP settings > DHCP) fail to get past this page even when the connection is already working. This points to the page's connection-check logic failing to detect a live connection, rather than any single button.

[AustinChangLinksys]

🔍 Automated investigation (preliminary triage)

Line: 2.x / USP (TR-369)

Root cause:

• Trigger (firmware/USP side): the device returns an empty {} payload for every USP GET in this session — 396 of 396 GET responses were empty, including Device.DeviceInfo.*, Device.WiFi.SSID.*, Device.PPP.Interface.* and, critically, the WAN status paths Device.IP.Interface.2.Status / .IPv4Address.1.IPAddress. USP login itself succeeded, so the transport is up but the data plane returns nothing.
• UI defect (PrivacyGUI): the PnP internet check cannot distinguish "a USP read failed / returned empty" from "the device confirmed there is no internet". Both collapse to the same NoInternet state, so "Try again" can never succeed while USP GETs return empty — even after the WAN cable is reconnected and the internet is genuinely back. There is no retry/backoff and no diagnostic surfaced to the user.

Evidence (from attached log.txt):

1. USP auth succeeded but every subsequent GET came back empty. Total GET responses vs. empty responses:

Total "GET ←"            : 396
"GET response EMPTY"     : 396

2. The WAN status GET — the exact call checkInternetConnected() depends on — returns {} (L416–L428):

#4 GET →
  [ "Device.IP.Interface.2.Status",
    "Device.IP.Interface.2.IPv4Address.1.IPAddress", ... ]
#4 GET ← (26ms)
  {}
#4 GET response EMPTY for paths: [Device.IP.Interface.2.Status, Device.IP.Interface.2.IPv4Address.1.IPAddress, ...]
#4 GET missing path in response: "Device.IP.Interface.2.Status"
#4 GET missing path in response: "Device.IP.Interface.2.IPv4Address.1.IPAddress"

3. Even DeviceInfo (a path that should always exist) came back empty, confirming the empty responses are not scoped to the WAN sub-tree (L383):

#1 GET ← (39ms)
  {}
#1 GET response EMPTY for paths: [Device.DeviceInfo.Manufacturer, Device.DeviceInfo.ModelName, ...]

4. Code path that turns this into a permanent error page (dev-2.5.0):
   • WanStatus.fetch (lib/generated/wan_status.g.dart) throws when fields are missing from the response:

if (missing.isNotEmpty) {
  throw 'Get failed: Validation error: Required fields missing from response: ...';
}

• PnpService.checkInternetConnected (lib/page/instant_setup/services/pnp_service.dart) rethrows that as a service error:

Future<bool> checkInternetConnected() async {
  try {
    final wan = await WanStatus.fetch(_usp);
    return wan.status == 'Up' && wan.ipAddress.isNotEmpty;
  } catch (e) {
    throw mapUspErrorToServiceError(e);   // read failure, not "no internet"
  }
}

• PnpNotifier._checkInternet (lib/page/instant_setup/providers/pnp_notifier.dart) catches any exception and unconditionally drops back to NoInternet:

} catch (e) {
  logger.e('[PnP] Internet check failed: $e');
  state = state.copyWith(phase: const NoInternet());   // same state as genuine no-internet
}

• "Try again" (retryInternetCheck) just re-runs _checkInternet(), so it loops back to the same page every time the GET stays empty — matching the reported "brief spinner then same error page".

Confidence: Medium — the UI resilience defect is confirmed in code + log, but the underlying trigger (why every USP GET returns empty despite a successful login) needs firmware-side confirmation of the device's actual behavior.

---

Auto-generated triage by Austin's tooling, pending Austin's review. Not a fix commitment.

[HankYuLinksys]

Root cause (code-confirmed on dev-2.6.0)

I verified the triage against the code. The UI-side defect is confirmed: the internet check cannot distinguish a USP read failure from a genuine "no internet", and collapses both into NoInternet.

The key insight is that the two cases are already distinguishable at the type level — the bug is that _checkInternet() throws that distinction away:

Case	Underlying behavior	Current result
Genuine no-internet (router reachable, WAN Status != 'Up')	GET succeeds → checkInternetConnected() returns false (no throw)	→ NoInternet ✅ correct
Read failure (router unreachable / empty {} GETs, as in this log)	WanStatus.fetch throws → mapped to InvalidInputError (code 9998)	→ catch unconditionally sets NoInternet ❌ wrong

Relevant code path:

• WanStatus.fetch throws when required fields are missing from the response — wan_status.g.dart
• PnpService.checkInternetConnected rethrows via mapUspErrorToServiceError — pnp_service.dart:89
• PnpNotifier._checkInternet catches any exception and falls back to NoInternet — pnp_notifier.dart:74

Why all three recovery options fail together: Try again, Restart your modem, and Enter ISP settings > DHCP all funnel back into _checkInternet(). So a single classification fix at that one point repairs all three flows — this is a check-logic defect, not three separate button bugs.

Decisions needed before implementing

1. Error UI for read-failure — dedicated "can't read router state" view (Try again + diagnostic code), or reuse the existing no-internet hub with swapped copy? (The restart-modem / ISP-settings options are meaningless for a read failure.)
2. Auto-retry with backoff — should a read failure auto-retry a few times (to absorb transient FW warm-up right after the WAN cable is reconnected), or ship the classification fix first and add retry later?
3. Scope vs. firmware — the FW-side trigger (why 396/396 GETs return empty after a successful login) still needs FW confirmation (need-fw-confirm). The UI fix is worth doing regardless, since it also hardens against any future transient read failure — but confirming whether this is expected FW behavior affects how aggressive the retry/copy should be.

Happy to proceed once the above are decided.

[HankYuLinksys]

Status update — app-side fix delivered, FW trigger still open

App side — done (PR #1132)

The UI-resilience defect is fixed. The internet check now distinguishes a read failure (USP GET returns empty / WanStatus.fetch throws) from a genuine no-internet (WAN read succeeds, Status != 'Up'), which previously collapsed into the same NoInternet state and made "Try again" loop forever.

• Read failure → new AdminReadFailure phase (was misreported as NoInternet).
• All check callers converge on the entry view, which re-runs the flow (implicit retry) and only settles on the read-failure card if it still fails — so "Try again", "Restart modem", and "Enter ISP settings" no longer dead-end.
• A genuine save-write failure stays on the ISP form + snackbar (unchanged).
• Regression tests added.

Important scope boundary

This fix improves the symptom, it does not make the internet work. While the firmware keeps returning empty for every GET, the user still cannot complete PnP setup — the app now just reports it clearly ("can't read router state" + retry) instead of misleading them into a no-internet loop. It also hardens the flow against any future transient read failure (e.g. FW warm-up right after the WAN cable is reconnected).

FW side — still open (need-fw-confirm)

The underlying trigger is unconfirmed: why does every USP GET return empty (396/396, incl. Device.DeviceInfo.*) after login succeeds? Login (transport) is up but the whole data plane returns nothing. This needs FW-side confirmation of whether it's a bug or expected behavior (e.g. a post-login readiness/timing gap). That answer is what actually unblocks PnP completion, and would also inform whether the app should add an automatic warm-up retry later.