[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.

Test Procedure: See ticket
Priority: P1
Risk: Low

[Copilot]

🔵 Needs a closer look

Hidden-SSID reporting and D-Bus reassociation need target-device validation for this recovery-critical change.

No open issues 🎉

What changed in this PR

This PR restores reliable Wi-Fi detection and self-healing after Wi-Fi toggles by removing dependence on the supplicant control socket.

Changes:

• Uses kernel-reported connection and SSID state, removing the /tmp/wifi-on gate.
• Requests reassociation over D-Bus and logs the result.
• Preserves telemetry markers and recovery escalation behavior.

File	Description
lib/​rdk/​networkConnectionRecovery.sh	Updates Wi-Fi detection and reassociation for recovery after toggles.

_{Review effort: Balanced}