Wi-Fi connect fails intermittently on WPA2/WPA3 transition-mode APs: 5 s carrier wait in network.sh might be too short (RG35XX Pro, 2601.1)

Issues 2601 Jacaranda
1

Device / version

  • Anbernic RG35XX Pro (H700), muOS 2601.1 Funky Jacaranda (full image + 2601.1 update applied)
  • Wi-Fi driver: Realtek RTW (as shown in dmesg), 2.4 GHz and 5 GHz tested

Symptom

  • On an access point in WPA2/WPA3 transition (mixed) mode, the auto-connect at boot and manual connects fail most of the time and are retried over and over. Sometimes one attempt succeeds by chance.
  • Because web services are only started after a successful connect, SSH is often not available even though the device ends up with an IP address a few seconds later (dhcpcd keeps running in the background).

What I measured

  • From wpa_supplicant start to /sys/class/net/wlan0/carrier = 1 (4-way handshake complete): 5.16 s / 5.17 s on 2.4 GHz, 6.18 s on 5 GHz on the transition-mode AP.
  • During the failing attempts dmesg shows assoc success followed by repeated rtw_aes_decrypt(wlan0) no_gkey_bc_cnt (group key not installed yet), then link is not ready when the connect is torn down.
  • On a WPA2-PSK-only SSID on the same AP hardware, the device connected on the first try 3 out of 3 times. I now use a dedicated WPA2-PSK-only SSID as a workaround.
  • DHCP itself is fast (the lease is granted right after the link comes up), so this is not a DHCP issue.

Where it happens (/opt/muos/script/system/network.sh, 2601.1)

WAIT_CARRIER() {
	[ "$IFCE" = "eth0" ] && return 0

	I=0
	while [ "$I" -lt 5 ]; do
		[ "$(cat /sys/class/net/"$IFCE"/carrier 2>/dev/null)" = "1" ] && return 0
		I=$((I + 1))
		sleep 1
	done

	LOG_ERROR "$0" 0 "NETWORK" "Link carrier timeout"
	FAIL_WITH "LINK_TIMEOUT" "$RC_LINK_TIMEOUT"
}

WAIT_NETWORK_ASSOC proceeds as soon as the SSID shows in iw dev wlan0 link (association, not handshake completion), so the whole 4-way handshake has to finish inside these 5 seconds. With ~5–6 s handshakes this becomes a race, and a lost race tears down the connection and starts TRY_CONNECT from scratch.

Possibly the same root cause in earlier reports

These all ended with “avoid mixed WPA2/WPA3”, which matches what I saw; the measurements above point at the fixed 5 s carrier window as the reason.

Suggestions

  1. Increase the carrier wait (e.g. 15 s), or make it a setting next to con_retry / wait_timer.
  2. Or wait on the supplicant state instead (wpa_cli -i wlan0 status → wpa_state=COMPLETED) rather than a fixed carrier window.

Related observation (separate issue, low priority)

  • The wpa_supplicant config written by web/password.sh contains only ssid / scan_ssid / psk (no key_mgmt, no ieee80211w), so WPA3-SAE-only networks cannot be joined. It may be worth documenting that WPA2-PSK (or transition mode) is required.

Thanks for muOS. It has been a joy to use.