WiFi Settings: Unable to change security mode to Enhanced Open Only

[KarenChen-Linksys]

Steps:

1. Go to Menu > WiFi Settings.
2. Change WiFi security mode to "OWE" and save.

Actual result:
Unable to change security mode to Enhanced Open Only.

Expected result:
Change security mode to Enhanced Open Only successfully.

Device
Pinnacle 2.0 FW: 1.2.2.26062820
Linksys Now Version: 2.5.0.700525

Additional context
Log: log.txt
Video: https://github.com/user-attachments/assets/a8569da7-28af-4db7-bcb8-20091dc7b7ba

[AustinChangLinksys]

🔍 Automated investigation (preliminary triage)

Affected version: Linksys Now 2.5.0.700525 (Pinnacle 2.0, FW 1.2.2.26062820) — codebase checked against dev-2.5.0.

Summary: Selecting OWE ("Enhanced Open Only") in WiFi Settings and saving reports no error, but the mode silently reverts to WPA3-Personal-Transition. Evidence points to a cross-layer issue with both a firmware-side and a UI-side component; firmware confirmation is needed to assign the primary cause.

Observed behavior (from the attached video + log):

• User opens the Security mode selector and picks OWE (video ~t6s; radio list is None / WPA2-Personal / WPA3-Personal / WPA3-Personal-Transition / OWE), then Save → "Processing…" → "Router is applying changes".
• UI sends the change and the backend returns success, echoing OWE back.
• ~1s later the post-save refresh reads the mode back as WPA3-Personal-Transition again — the change did not stick.

Evidence:

1. The device does advertise OWE as supported, and the starting mode was WPA3-Transition (log L408–L413):

"Device.WiFi.AccessPoint.1.Security.ModesSupported": "None,WPA2-Personal,WPA3-Personal,WPA3-Personal-Transition,OWE",
"Device.WiFi.AccessPoint.1.Security.ModeEnabled": "WPA3-Personal-Transition",

2. On Save the UI issues two SETs writing ModeEnabled: "OWE" — backend returns success: true and echoes OWE (log L6968–L6998):

#46 SET →
  { "Device.WiFi.AccessPoint.1.Security.ModeEnabled": "OWE", "Device.WiFi.AccessPoint.1.SSIDAdvertisementEnabled": true }
#46 SET ← (1112ms)
  { "success": true, "result": { "data": {
      "Device.WiFi.AccessPoint.1.SSIDAdvertisementEnabled": "true",
      "Device.WiFi.AccessPoint.1.Security.ModeEnabled": "OWE" } } }

(#47 does the same for AccessPoint.2, also success: true.)

3. The very next refresh (~15:51:56) reads the mode back as WPA3-Personal-Transition, not OWE (log L7132–L7133):

"Device.WiFi.AccessPoint.1.Security.ModeEnabled": "WPA3-Personal-Transition",
"Device.WiFi.AccessPoint.2.Security.ModeEnabled": "WPA3-Personal-Transition",

So firmware acknowledged OWE with success:true but did not actually commit it.

4. String-mismatch on the UI side. Throughout the codebase the canonical open-enhanced string is Enhanced-Open, not OWE:
   • usp_wifi_settings_service.dart:594,603-604 (6 GHz override) treats {'None', 'Enhanced-Open', ''} as the open set and sends Enhanced-Open.
   • wifi_network_ui_model.dart:108 and wifi_settings_settings.dart:55 both test securityMode == 'Enhanced-Open' to decide "is open" (e.g. whether a password is required).
   • For 2.4/5 GHz, saveAdvanced (usp_wifi_settings_service.dart:401-402) sends securityMode verbatim from the selector, which is populated from the firmware's ModesSupported string — here OWE. So the value written (OWE) is a string the rest of the UI does not recognize as an open mode.

Two components (needs firmware confirmation to rank):

• Firmware side: OWE is advertised in ModesSupported and accepted with success:true, yet the readback reverts to WPA3-Transition — the SET is not committed. Needs firmware to confirm whether OWE is a genuinely settable value on this build/model or only reported as supported.
• UI side: the selector forwards the raw ModesSupported token (OWE) while the rest of the WiFi code standardizes on Enhanced-Open; there is no mapping between the two, and the user gets no error when the write silently fails to apply.

Confidence: Medium — the symptom and the SET/readback contradiction are fully confirmed from the log; root-cause ownership spans the UI↔firmware boundary and needs firmware to confirm whether OWE is a settable value here. How to reconcile the OWE/Enhanced-Open token mismatch and surface a failure to the user is a design decision for the team.

---

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

[HankYuLinksys]

On-device probing (Pinnacle 2.0, FW 1.2.2.26062820) confirmed this is a two-layer issue. The app side is fixed in #1142; the firmware side remains.

App side — fixed in #1142
The code used 'Enhanced-Open', but firmware only accepts the TR-181 token OWE (it rejects 'Enhanced-Open' as "Out of range or invalid enumeration"). This caused two latent bugs, now corrected:

• 6 GHz open mode sent the invalid 'Enhanced-Open' token.
• OWE networks were not recognized as open, so the UI spuriously required a password and blocked Save.

The app now sends the valid OWE token on all bands and treats OWE as an open mode.

Firmware side — still open
Even with the correct OWE token, firmware accepts the SET with success: true (echoing OWE) but does not commit it — the readback reverts to the previous mode. EncryptionMode is read-only, so no client-side field combination makes OWE stick.

#1073 will remain reproducible until the firmware commit bug is fixed. The remaining work is on the firmware team.