Ive had a reproducible issue here connecting my Beryl to 1 specific home ISP router on 5GHz only and getting an IP.
Beryl AX running 4.9 beta 4 (but also on 3,2 and 1 but cant confirm older).
Beryl AX running in Router mode to repeat the wifi via its own network.
ISP Router is IndoHome which is a rebadged Huawei HG8145V5.
Importantly its set to WPA/WPA2PSK and “TKIP&AES” as a default. An old encryption scheme. This is the default shipped.
Problem
- Beryl connects to the ISP router using 2.4ghz, DHCP works, an IP is assigned and no issues.
- However on 5GHz it connects BUT DHCP allocation never completes, times out and gets into a reconnect cycle loop.
- If i MANUALLY assign an ip address, subnet etc it works on 5GHz.
No other devices at all have this issue.
Every connection attempt shows the same sequence. The 4-way handshake reaches message 3 and then logs an RSNIE mismatch:
7981@C15L3,PeerPairMsg3Action() 6640: ===>Receive msg 3
WiFi@C15L1,RTMPCheckRSNIE() 4543: WPA/WPAPSK IE mis-matched
IPv6: ADDRCONF(NETDEV_CHANGE): apclix0: link becomes ready
Despite the mismatch the association completes and gl-repeater reports connected:
7981@C09L2,LinkUp() 3102: BssType=1, AID=91, ssid=[SSID], Channel=149, CentralChannel = 155
gl-repeater: connected to [SSID] [BSSID]
gl-repeater: [no-ip] schedule recover check delay: 15 ip_wait_time: 15
DHCP discovers are sent but no offer is ever received:
netifd: wwan (4315): udhcpc: started, v1.33.2
netifd: wwan (4315): udhcpc: sending discover
netifd: wwan (4315): udhcpc: sending discover
netifd: wwan (4315): udhcpc: sending discover
After 15 seconds, gl-repeater gives up and tears down the connection:
gl-repeater: [no-ip] no ipv4 address on wwan reconnect to known bss
gl-repeater: remove "apclix0" from wwan
This cycle repeats indefinitely. The Beryl then restores its own downstream 5 GHz radio to its resting channel and reschedules a retry in 30 seconds:
gl-repeater: rax0 restore channel to 40
gl-repeater: switch in 30 seconds..
Pool exhaustion, ip conflict and mac filtering ruled out.
A summary (using AI because of my own random jumpy notes):
The upstream router is configured with WPA/WPA2 mixed mode and TKIP&AES. This is a legacy security configuration that causes ambiguity in the RSN Information Element (RSNIE) cipher suite negotiation during the 4-way handshake. The IE presented in handshake message 3 can differ from what was advertised during association, which the MT7981 driver correctly detects and logs as WPA/WPAPSK IE mis-matched.
The driver does not drop the connection on this error — it completes the association, which is the correct behaviour for compatibility with older routers. However, the upstream router enters a half-open session state for that client as a result of the inconsistency. In this state it processes unicast traffic normally but silently drops broadcast traffic from the client.
DHCP discover packets are sent to the broadcast address 255.255.255.255 and are therefore discarded before reaching the router's DHCP server. This explains why a pre-configured DHCP reservation on the router makes no difference — the reservation is irrelevant if the discover never arrives.
Assigning a static IP bypasses broadcast entirely. The Beryl ARPs for the gateway via unicast, which the router handles normally, and the connection functions correctly.
The 2.4 GHz band on the same router works via DHCP because the cipher suite negotiation path differs slightly between bands on this router, resulting in a consistent RSNIE and no half-open session state.
The RSNIE mismatch log line is the key indicator. The combination of:
-
Association succeeding
-
RSNIE mismatch logged
-
DHCP failing silently
-
Static IP working
-
DHCP reservation also failing
