[tukken-comcast]

Reason for change: Fix false TELEMETRY_WIFI_NOT_CONNECTED after wifi toggle

Details: In the network connection recovery script, checkWifiConnected() determined wifi state with "wpa_cli status", which needs wpa_supplicant's per-interface control socket. NetworkManager creates supplicant interfaces over D-Bus passing only Driver and Ifname, so an interface it re-creates gets an empty config with no ctrl_interface and no socket. Any wifi toggle (SetInterfaceState, nmcli radio wifi off/on, rfkill) therefore leaves wpa_cli broken for the life of the wpa_supplicant process.

The probe then reported "not connected" while wifi was up. That logged a false TELEMETRY_WIFI_NOT_CONNECTED and, worse, left both IsEthernetConnected and IsWifiConnected at 0 so neither branch of the main flow ran: no gateway packet-loss telemetry and no wifi recovery ladder until the next maintenance reboot.

Take wifi state from the kernel instead, so the probe cannot be broken by the subsystem it is watching:

• checkWifiConnected() uses "iw dev link" (nl80211), which needs no control socket, no daemon and no config prerequisite. The LNF SSIDs are hidden, so the SSID used for the LNF match comes from "iw dev info" (kernel station state), falling back to the SSID: line of "iw link".
• Drop the /tmp/wifi-on gate, a second piece of derived state that can drift and produce the same symptom. The file and its other producers and consumers are unchanged.
• wifiReassociate() calls fi.w1.wpa_supplicant1.Interface.Reassociate over D-Bus instead of "wpa_cli reassociate". Both are wpas_request_connection() behind the same WPA_INTERFACE_DISABLED guard, so the operation is identical, but D-Bus does not depend on the control socket. The wpa_cli form is kept as a comment because it remains the short hand-run equivalent for triage.
• Log whether the reassociate was actually performed. IsWifiReassociated stays unconditional: it is the escalation rung counter, and gating it on success would stop the ladder ever reaching wifiReset.

Telemetry markers and every t2CountNotify call are byte-identical, and escalation timing is unchanged. Verified on an 8.6 build, including LNF detection on a device connected to the LNF enterprise SSID.

Test Procedure: See ticket
Priority: P1
Risk: Low

[Copilot]

🟢 Approval recommended

No blocking issues were identified in the focused changes or their recovery-flow integration.

0 open findings

What changed in this PR

Fixes false Wi-Fi disconnection reports and stalled recovery after Wi-Fi toggles by removing reliance on the supplicant control socket.

Changes:

• Uses kernel Wi-Fi state and removes the /tmp/wifi-on gate.
• Reassociates over D-Bus and logs outcomes while preserving recovery escalation and telemetry markers.

File	Description
lib/​rdk/​networkConnectionRecovery.sh	Updates Wi-Fi detection and reassociation to remain functional after toggles.

🧠 Review effort: Balanced

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.