Device: GL-MT300N-V2 (Mango) Firmware tested: v4.3.29 (beta, latest available) and v4.3.25 (latest stable) — issue reproduces identically on both Upstream AP: Nokia WiFi Beacon (mesh system), WPA2-Personal/AES
Summary:
When connecting to a Nokia WiFi Beacon access point in Repeater/Extender mode, the log reports a successful connection (e.g. connected to 'SSID(BSSID)' channel: X, spent Ys), but no actual data traffic passes over the link. udhcpc sends repeated DHCP discovers with no offer ever received, eventually triggering the repeater script's "NO IP for long time, down/up apcli0" recovery loop, which cycles indefinitely and ultimately reverts the device to Router mode. This behavior is identical across both the stable (4.3.25) and beta (4.3.29) firmware branches, ruling out a regression specific to either release.
Diagnostic steps taken:
Confirmed signal strength and physical proximity are not the issue (Mango placed directly next to the AP).
Confirmed WPA2 password is correct (verified character-by-character against the AP).
Confirmed AP is not using MAC filtering or client isolation.
Confirmed AP's own DHCP/backhaul path works correctly for other clients.
Assigned a static IP manually to apcli0 after a successful "connected" log line and attempted to ping the AP directly — 100% packet loss, even to the AP's own gateway IP, despite the interface reporting link connectivity.
Disabled encryption entirely on the AP (Open network) — Mango immediately obtained a DHCP lease and ping succeeded with 0% packet loss. This isolates the issue specifically to the WPA2/AES handshake completion, not to DHCP, MAC address, signal, or physical layer.
Attempted to set ieee80211w=0 on the sta wifi-iface via UCI to force-disable PMF negotiation from the client side — this section is dynamically managed by the closed-source /usr/sbin/repeater binary (confirmed via Lua bytecode header) and cannot be persistently modified via UCI or the web UI.
Suspected root cause:
PMF (802.11w) negotiation failure between the MT7628's wpa_supplicant/driver stack and the Nokia Beacon's AP, similar to reports in other threads on this forum (e.g. the Beryl/MT1300 WPA3 kernel log showing "PMF connection, Ignore AddBaReq... DUE TO NOT IN PORTSECURED"). Association (L2) completes, but the 4-way handshake / PMF negotiation appears to silently fail, leaving the link non-functional despite reporting "connected."
Requested fix / feature:
Please expose a way to disable or force-optional PMF/802.11w specifically on the client (STA) interface used in Repeater mode — either via the web UI or by allowing persistent UCI overrides that the repeater script won't overwrite.
Full logread output and MAC address details available on request.
We have recorded this issue and submitted it to our development team for further investigation.
As a temporary workaround, please SSH into the Mango and run the following commands:
iwpriv apcli0 set PMFMFPC=0
iwpriv apcli0 set PMFMFPR=0
iwpriv apcli0 set PMFSHA256=0
These commands disable the PMF capability, PMF requirement, and related SHA-256 negotiation on the repeater client interface apcli0, allowing it to connect as a standard WPA2-PSK client.
This does not disable WPA2/AES encryption for normal data traffic. However, management frames such as deauthentication and disassociation frames will no longer be protected by PMF. If the upstream Wi-Fi requires PMF, the Mango may not be able to connect.
After running the commands, please disable and reconnect the Repeater connection, then check whether the Mango can obtain an IP address normally.
We will continue to follow up with our development team and update you once there is further progress.
Thank you for your feedback and patience.
Thank you for the workaround suggestion. I tested it, but unfortunately it did not resolve the issue.
Steps taken:
Ran all three commands as instructed:
iwpriv apcli0 set PMFMFPC=0
iwpriv apcli0 set PMFMFPR=0
iwpriv apcli0 set PMFSHA256=0
Disabled and re-enabled the Repeater connection afterward, as instructed.
Result: identical failure pattern as before — connects successfully at L2, then udhcpc fails to obtain a lease, followed by the "NO IP for long time, down/up apcli0" recovery loop.
Further testing:
Since the repeater script (/usr/sbin/repeater) frequently cycles the mt7628 radio and apcli0 interface up/down as part of its normal reconnect logic, I suspected the iwpriv settings might be getting reset on each cycle (since they appear to be runtime-only, not persisted to a profile that survives an interface restart). To test this, I ran the three commands in a continuous loop (every 1 second) in a separate SSH session while attempting to reconnect:
while true; do iwpriv apcli0 set PMFMFPC=0; iwpriv apcli0 set PMFMFPR=0; iwpriv apcli0 set PMFSHA256=0; sleep 1; done
Even with continuous reapplication, the connection still fails with the same DHCP timeout pattern. This suggests either:
The settings are being reset/reapplied at a point in the connection sequence that's too late (e.g., after the 4-way handshake has already started or failed), or
The apcli0 interface referenced by these iwpriv commands isn't the same internal radio context the repeater script uses for the actual association, or
The repeater script resets these driver-level flags through a mechanism other than a simple interface down/up (e.g., a full driver reload).
I'm happy to provide additional log captures or run further diagnostic commands if that would help narrow this down further on your end. Thank you again for looking into this.