MT-3000 Beryl AX Intermittent Disconnection in Repeater Mode

I recently bought an MT-3000 from Amazon to use it as a repeater for a public WiFi. However, I ran into the problem that MT-3000 would suddenly disconnect from the upstream wireless network every few minutes or hours. When I check the admin portal at this point, it shows consistent attempts to reconnect. However, it won’t reconnect, unless I abort the reconnection and manually connect again in the repeater manager. It is very annoying as I disconnect from the internet every so often and this makes this router totally unusable.

I managed to retrieve the log when MT-3000 disconnected from the upstream WiFi:

Fri Oct 20 20:32:10 2023 kern.err kernel: [64297.805795] 7981@C09L1,ApCliIfMonitor() 2987: STA Beacon loss condition got hit.
Fri Oct 20 20:32:10 2023 kern.debug kernel: [64297.813196] ApCliIfMonitor : band_idx=1 Trigger TX AUTO DBG!
Fri Oct 20 20:32:10 2023 kern.debug kernel: [64297.818845] mt7981_hw_auto_debug_trigger : BandIdx=1, module=1, reason=0
Fri Oct 20 20:32:10 2023 kern.warn kernel: [64297.825744] WiFi@C09L2,cntl_disconnect_request() 450: caller:ApCliIfMonitor+0x3f4/0x908 [mt_wifi],type=1,reason=8
Fri Oct 20 20:32:10 2023 kern.notice kernel: [64297.836193] 7981@C09L3,sta_mlme_disassoc_req_action() 2147: ASSOC - Send DISASSOC request[BSSID::72:a7:41:9e:05:8f (Reason=8)
Fri Oct 20 20:32:10 2023 kern.notice kernel: [64297.847569] 7981@C09L3,sta_cntl_disassoc_conf() 1821: CNTL - Dis-associate successful
Fri Oct 20 20:32:10 2023 kern.notice kernel: [64297.855453] 7981@C23L3,operate_loader_phy() 394: oper_cfg: prim_ch(149), ht_bw(1), extcha(1), vht_bw(1), cen_ch_2(0), PhyMode=177!
Fri Oct 20 20:32:10 2023 kern.notice kernel: [64297.867191] 7981@C23L3,operate_loader_phy() 408: oper_dev after adjust: bw(2), prim_ch(149), cen_ch_1(155), cen_ch_2(0),ext_cha(1)!
Fri Oct 20 20:32:10 2023 kern.notice kernel: [64297.879025] 7981@C23L3,operate_loader_phy() 428: oper_radio after decision: bw(2), prim_ch(149), cen_ch_1(155), cen_ch_2(0)!
Fri Oct 20 20:32:10 2023 kern.notice kernel: [64297.890320] 7981@C03L3,MtCmdChannelSwitch() 2538: ctrl_chl=149, ctrl_ch2=0, cent_ch=155 DBDCIdx=1, ChBand=1, BW=2, TXStream=3, RXStream=3, scan(0)
Fri Oct 20 20:32:10 2023 daemon.notice netifd: Network device 'apclix0' link is down
Fri Oct 20 20:32:10 2023 daemon.notice netifd: Interface 'wwan' has link connectivity loss
Fri Oct 20 20:32:10 2023 daemon.notice netifd: wwan (4131): udhcpc: received SIGTERM
Fri Oct 20 20:32:10 2023 daemon.notice netifd: wwan (4131): udhcpc: unicasting a release of 192.168.1.213 to 192.168.1.1
Fri Oct 20 20:32:10 2023 daemon.notice netifd: wwan (4131): udhcpc: sending release
Fri Oct 20 20:32:10 2023 daemon.notice netifd: wwan (4131): udhcpc: entering released state
Fri Oct 20 20:32:10 2023 daemon.notice netifd: wwan (4131): Command failed: Permission denied
Fri Oct 20 20:32:10 2023 daemon.notice netifd: Interface 'wwan' is now down
Fri Oct 20 20:32:10 2023 daemon.notice netifd: Interface 'wwan' is disabled
Fri Oct 20 20:32:10 2023 daemon.info avahi-daemon[5271]: Withdrawing address record for 192.168.1.213 on apclix0.
Fri Oct 20 20:32:10 2023 daemon.info avahi-daemon[5271]: Leaving mDNS multicast group on interface apclix0.IPv4 with address 192.168.1.213.
Fri Oct 20 20:32:10 2023 daemon.info avahi-daemon[5271]: Interface apclix0.IPv4 no longer relevant for mDNS.
Fri Oct 20 20:32:10 2023 daemon.notice netifd: Interface 'wwan' is enabled
Fri Oct 20 20:32:10 2023 user.notice firewall: Reloading firewall due to ifdown of wwan ()
Fri Oct 20 20:32:10 2023 kern.notice kernel: [64298.102335] 7981@C03L3,MtCmdSetTxRxPath() 2799: ctrl_chl=149, ctrl_ch2=0, cent_ch=155, RxPath=7, BandIdx=1, ChBand=1, BW=2,TXStream=3, RXStream=7, scan(0)
Fri Oct 20 20:32:10 2023 kern.err kernel: [64298.117401] 7981@C12L1,EDCCAInit() 21006: EDCCA compensation: uni_compensation=0, bw_compensation=0, final compensation=0
Fri Oct 20 20:32:10 2023 kern.warn kernel: [64298.128561] 7981@C01L2,wifi_sys_disconn_act() 1002:  wdev_idx=5
Fri Oct 20 20:32:10 2023 kern.notice kernel: [64298.135995] 7981@C08L3,hw_ctrl_flow_v2_disconnt_act() 172: wdev_idx=5
Fri Oct 20 20:32:10 2023 kern.warn kernel: [64298.143628] 7981@C13L2,MacTableDeleteEntry() 1793: Del Sta:72:a7:41:9e:05:8f
Fri Oct 20 20:32:10 2023 kern.notice kernel: [64298.150899] 7981@C01L3,wifi_sys_linkdown() 1363: wdev idx = 5
Fri Oct 20 20:32:10 2023 kern.debug kernel: [64298.157632] del link apclix0
Fri Oct 20 20:32:10 2023 kern.notice kernel: [64298.159050] 7981@C08L3,hw_ctrl_flow_v2_link_down() 123: wdev_idx=5
Fri Oct 20 20:32:10 2023 kern.debug kernel: [64298.160509] nf_unregister_hooks()
Fri Oct 20 20:32:10 2023 kern.debug kernel: [64298.170154] del path: rax0(UP)->apclix0(DN), active path:2
Fri Oct 20 20:32:10 2023 kern.debug kernel: [64298.175727] nf_register_hooks()
Fri Oct 20 20:32:10 2023 kern.debug kernel: [64298.180957] del path: rax1(UP)->apclix0(DN), active path:1
Fri Oct 20 20:32:10 2023 kern.debug kernel: [64298.186512] nf_unregister_hooks()
Fri Oct 20 20:32:10 2023 kern.debug kernel: [64298.190010] del path: eth1(UP)->apclix0(DN), active path:0
Fri Oct 20 20:32:10 2023 user.notice kmwan: config json str={ "op": 3, "data": { "cells": [ "wwan" ] } }
Fri Oct 20 20:32:10 2023 kern.debug kernel: [64298.256999] ================kmwan:[config_handle 372]op:3==============
Fri Oct 20 20:32:10 2023 kern.debug kernel: [64298.263679] [remove_dev_config 174]delete node, interface:wwan
Fri Oct 20 20:32:11 2023 kern.warn kernel: [64299.193656] 7981@C09L2,cntl_connect_request() 395: type=2,len=0,caller:ApCliIfUp+0x190/0x348 [mt_wifi]
Fri Oct 20 20:32:12 2023 daemon.err lua: (...arch64_cortex-a53/gl-sdk4-repeater/usr/sbin/repeater:1258) disconnected, wait reconnect...
Fri Oct 20 20:32:13 2023 kern.debug kernel: [64300.760841] BcnCheck start after 2500 ms (ra0)
Fri Oct 20 20:32:13 2023 kern.debug kernel: [64300.765286] BcnCheck start after 2500 ms (ra0)
Fri Oct 20 20:32:13 2023 kern.warn kernel: [64301.220749] 7981@C09L2,sync_fsm_join_timeout_action() 1091: ProbeTimeoutAtJoinAction
Fri Oct 20 20:32:13 2023 kern.warn kernel: [64301.289109] 7981@C09L2,cntl_connect_request() 395: type=2,len=0,caller:ApCliIfUp+0x190/0x348 [mt_wifi]
Fri Oct 20 20:32:13 2023 kern.err kernel: [64301.298427] 7981@C09L1,cntl_connect_request() 412: Return since CNTL not IDLE,CNTL(1),SYNC(2),AUTH(0),ASSOC(0)
Fri Oct 20 20:32:15 2023 kern.warn kernel: [64303.236243] 7981@C09L2,sync_fsm_join_timeout_action() 1091: ProbeTimeoutAtJoinAction
Fri Oct 20 20:32:15 2023 kern.warn kernel: [64303.384592] 7981@C09L2,cntl_connect_request() 395: type=2,len=0,caller:ApCliIfUp+0x190/0x348 [mt_wifi]
Fri Oct 20 20:32:15 2023 kern.err kernel: [64303.393917] 7981@C09L1,cntl_connect_request() 412: Return since CNTL not IDLE,CNTL(1),SYNC(2),AUTH(0),ASSOC(0)

I’m not sure what the problem is, like I see STA Beacon loss condition got hit, but for what reason?

Here’s my network configuration, if it helps:

  • Upstream WiFi is a 5GHz public WiFi (80 MHz and channel 149, NOT using DFS channels or having any nearby), with WPA2 security and NO captive portal. Also I don’t think there’re connectivity issues for the signal strength is consistently above -70dbm with no interference.
  • I have Lock BSSID ON (to make sure MT-3000 connects to AP at 5GHz instead of 2.4 for better network performance); manual static IP OFF; Allow switching to other saved networks ON (I think this doesn’t make a real difference as the upstream WiFi is the only saved network)
  • Adguard, VPNs, IPV6 or Tor all disabled
  • Firmware at 4.5.0 beta (also tried 4.4.5/4.4.6 stable & reset firmware several times, but same issue here)

Could anyone help me with possible causes/solutions?

2 Likes

Do you have connection monitoring on? There’s a timeout on downstream so if you have it set too low it’ll drop the connection. Set it for 30 to 60 seconds or turn it off/make it permanently connected.

Check the device it is connecting to for faults and reboots as downstream died.

5g isn’t necessarily faster. If you’re close by then yes it should be but if not then 2.4 will have a better throughput.

Channel 147 is DFS but I think it is a legal channel in the UK and some other countries?

80mhz offers more bandwidth but it also offers more interference. Use 20mhz or 40mhz for less interference.

Turn network switching off for now until you figure why.

Thanks for your reply.

  1. Connection monitoring: Yes, I do have it on. But I did consider whether this setting would cause the disconnection as well, and I set it to ping every 60 seconds which should be long enough.
  2. AP that my router connects to: I don’t see there’s any problem or rebooting with it, but I cannot make 100% sure, since it’s public WiFi and I have no access to the admin portal.
  3. 5G/2.4G: I’ve tested both frequencies before deciding to stick to 5G. 2.4G gives a download speed at ~80Mbps while 5G can go over 150Mbps (even 200+Mbps if wired connected to MT-3000) in my case.
  4. DFS: I’m in Australia and I don’t think channel 149 requires DFS here (?), according to Wikipedia.
  5. I’m unable to modify bandwidth/channel in repeater mode so I guess I’ll have to use 80MHz.

For now I’ll disable connection monitoring & network switching to see if it helps. And thanks again for your tips :slight_smile:

It could be that the amount of devices on the public wifi has reached it’s limit so to let someone on they kick someone off. I had a similar issue at home using hundreds of IoT devices on one network… Had to split the network up into chunks to prevent one single device kicking the entire network one by one to infinity.

Use guest network with IoT. Breaks it up a little. I think someone mentioned you could set up more guest networks but think it may be something you need to do in Luci.

I have. I run 2 beryl’s for my cameras and IoT that are more local to them. Then a flint running 80+ devices then a beryl AX running it’s local devices and doing the multiwan thing… All of those are using main and guest.

I also have another flint ready to connect to the network because more devices are about to be installed. I used to use a mesh system but quickly out grew it…

Some quick updates on how I’ve been trying to debug in the past few days:

  • I reinstalled the latest 4.5.0 beta (built on 23 Oct) firmware using Uboot to completely troubleshoot the firmware/settings issue, but it didn’t work.
  • I turned off network switching, network monitoring, or both, neither of which seemed to work.

Given the complexity of the public wireless network environment, I could only blame the problem on the upstream AP.

However, I may have found a temporary workaround: I reinstalled the latest 4.4.6 stable firmware last night, and set the wireless client protocol to 802.11ac (instead of the default ax) in Luci (under Luci > Network > Wireless > Choose the “client” that connects to upstream AP > operating mode). Now my router seems to be working properly for a day. However, if the router reboots, it will be changed back to default ax, and I’m not even sure whether it’s this option or luck that works…

I guess it’s either a problem with the upstream AP or with the router’s wireless driver. I’ll update if any new issues come up.

If you use luci you will probably always get conflicts with the built-in GL. A temporary solution to avoid resetting the settings would be to use this method

I’ve read a fair bit that 4.5 has some bugs… but best thing to do report and perhaps downgrade to a stable release to avoid issues…

Some further updates:

Now I can almost conclude that my problem was caused by the upstream AP… I connected to another AP about a week ago, and since then the router has been working flawlessly w/o any disconnection. Anyway I’ll be finishing my travel and returning home by the end of this month, when I’ll test the router on my home network. If it’s working then as well, I’ll close this thread.

PS: Firmware 4.4.6 stable isn’t that stable in my case. I’ve had several times when I couldn’t connect to WiFi after a reboot. I’d say 4.5.0 beta is currently the best firmware for MT3000 with no noticeable issues.

All the 4.x firmwares have loads of bugs and edge cases with Repeater mode. You’ll be lucky to get it stable after hours of tinkering, even with a GL-iNet device as the upstream. :person_shrugging:

Edit: I came back to update this to be a little more realistic. Even with the 4.x Repeater Mode bugs, there is usually some magic combo of settings where the device will be stable and work well in this mode, as long as you have sufficient signal strength.

Some devices are a lot worse than others, though. Using Creta as a repeater running 4.x (with a Slate AX upstream) is way, way, WAY worse than Creta as a repeater running 3.216. After hours of pain I gave up on the Creta running 4.x, swapped in the Slate Plus with 4.x that I usually keep in my backpack, and it Just Worked immediately with zero fiddling. Yet that same Slate Plus acts strangely in other ways, and requires much more fiddling with some other upstream devices. :person_shrugging:

GLi devices are really great when they work, I use them every day of my life and am about to buy another one, but there are a lot of bug-related traps even for experienced users on the path to getting them stable for certain use cases, especially on 4.x.

1 Like

We will update MT3000, try switch to Open source wifi driver. Maybe it will improve a lot in repeater mode.

@alzhao Can you please post a link to the open source driver?

That’s good news to hear and thanks for your team’s work! I’ve been testing my MT-3000 on my home network for the past ~2 weeks and it works well in repeater mode (upstream ASUS RT-AC68U 5GHz, and MT-3000 on firmware 4.5.0 beta). So I guess my problem before was with the upstream AP… Anyway I’ll mark this thread as solved for now.

1 Like

I don’t yet have this firmware. I will push the team for it.

Looking forward to testing, hopefully it fixes the problem!

I installed OpenWRT 23.05.2 and the router is much more stable: no crashes at the moment (6 days and counting) when it used to be between 1 to 3 days max. The 5GHz Wi-Fi is working without issues, so it would be great to push the Dev team for the new open source driver. Otherwise I won’t be able to use the wonderful gl-inet web UI, which is one of the strong selling points of gl-inet routers.

3 Likes

Thanks for the feedback. I will push.

1 Like

Does MT3000 OpenWRT installation boil down to a sysupgrade or there’s more to it?

Just a sysupgrade. To revert back to gl-inet firmware you have to use the uboot firmare version (instead of the local upgrade for web Admin Panel) and follow the uboot instructions.

1 Like