GL-AR300M16-Ext disconnecting and failing to reconnect to wifi

WonTon79 · March 13, 2026, 9:49am

Hi,

I’ve a frustrating issue with a GL-AR300M16-Ext.
The device is in a remote location and is being used to access a dumb ethernet device. It connects to a local wiregaurd server so we can access the device locally.

The device is losing WiFi connection and will not reconnect. Usually powercycles will not resolve this.

The last three times this happened, I had to go to the remote location, connect to the device, then manually reconnect the router to the local wifi, this resolved the issue.

It happened again today and I luckily had the time to delve into it a bit deeper.

On visiting the remote location, the logs where a bit useless as they just show the device constantly trying to reconnect to the wiregaurd server, which won’t work as the wifi is down.

Connecting to the device myself and trying to manually connect the wifi didn’t work, in fact it could not see any networks.

However this time a power cycle did resolve the problem. As soon as I powered cycled it, the unit connected to the wifi automaticaly and the wiregaurd server connected straight away. I’m wondering did my manual attempt at connecting to the wifi before the power cycle help in some way?

I’ve logs from the unit before I restarted it, but not sure where to post these as they have confidential information.

It’s my first time using one of these devices in this configuration, and we as a company where using this as a test bed to see if they where suitable for remote monitoring of equipment. This is a very power showing as a first trial.

Thans for your time,

JB

will.qiu · March 13, 2026, 9:51am

Hi

Please send us the logs via private message.
We will conduct further analysis.

WonTon79 · March 13, 2026, 12:46pm

That’ sent now will.

will.qiu · March 16, 2026, 3:14am

Thanks for providing the logs.

After reviewing them, we found that the AP the AR300M is connected to keeps switching between 20 MHz and 40 MHz channel width on 2.4 GHz, which appears to be causing the issue.

Could you please:

Provide the current 2.4 GHz configuration of the upstream AP?
Try fixing the channel and channel width on the upstream AP and see whether the issue occurs again?

WonTon79 · March 16, 2026, 4:59pm

Hi,

I don’t have any access to the upstream AP as it’s not owned by me.

I think channel width on the AR300M is set to 20Mhz, would setting it to auto resolve this?

Why is the channel width changing causing the AR300M to fail?

will.qiu · March 17, 2026, 8:32am

You can try it—it may help.

The upstream AP is requiring the AR300M to switch to a combination it does not support

WonTon79 · March 27, 2026, 10:03am

OK, so here’s what I don’t understand.

If that’s the case, why when I connect to the ARM300M WiFi, then disconnect, then leave it alone for a miniute, do it just fix itself? I’ve sent another log to you, you’ll see this behaviour at around 8:30am.

eric · March 27, 2026, 3:26pm

@WonTon79 I’m not an employee of GL iNet, but just a user of multiple AR300M and AR300M16 routers. I am not sure if you have searched through the forum, but there are a couple recent reports of connection issues with AR300M, including this one:

As you are using your AR300M16 for remote monitoring, and not as a travel router, you may want to test it with generic OpenWrt firmware instead of the GL iNet firmware, as this firmware is much more configurable for non-travel routers usage.

I use the AR300M as remote VPN servers, in location I do not have easy access to, and not as a travel routers. The OpenWrt version has worked better for me, as GI iNet adds a lot of changes to the OpenWrt firmware to make it a travel router, that sometimes gets in the way of using it for other purposes. There are also some tools within OpenWrt to be able to reboot the router if connection is lost to the remote system.

See: https://firmware-selector.openwrt.org/

butterfry · March 28, 2026, 4:35pm

just as a data point - the manual lock to 20mhz on 2.4 switch was one of the first things i tried to mitigate this situation months ago. I’ve at least 60 in the wild right now locked to 20mhz. this didn’t seem to mitigate the disconnect > no reconnect situation.

I think it IS an artifact of upstream router. One thing I will start to gather is what exactly is the upstream routers that we’re trying to connect to. I don’t have that information, but we need to be resilient enough to at least reconnect if the host AP is acting out of spec.

WonTon79 · March 29, 2026, 3:53am

I’m already considering this, but the AR300M and a GSM USB dongle. I just don’t want to commit to that just yet.

I think it IS an artifact of upstream router.

@butterfry I don’t disagree that whatever happens is kicked off by the upstream router causing something. However in my mind that doesn’t matter.

The issue is that the AR300M makes no attempt to rectify the situation. I actually have the unit set to reboot every night, but once it gets kicked off it still won’t attempt to reconnect.

However, if I connect my laptop to it over WiFi, then disconnect from it (That’s all, nothing else!!) it will fix itself! Like there’s clearly something wrong there.
I don’t know if it’s my laptop attempting an outbound connection using the WiFi that makes the AR300M realise it should probably do something about the broken connection, but this should be built into the firmware.

will.qiu · March 30, 2026, 3:01am

Thank you for providing the logs—we’ll review them with the R&D team.

will.qiu · March 30, 2026, 6:42am

After reviewing the logs, we found that this set of logs contains more useful information beyond just kernel logs provided last time, which allowed us to gain better insight into the situation. At present, it appears to be somewhat different from what you initially observed.

The root cause is weak signal and/or heavy interference, which causes the upstream AP to frequently switch channels and the AR300M to disconnect and reconnect from time to time.

From the logs, we observed two offline events:

1. Disconnection caused by the upstream AP switching to an unsupported ECSA IE operating class

Disconnection:

Fri Mar 27 01:56:35 2026 kern.info kernel: [178948.506904] wlan-sta0: failed to use reserved channel context, disconnecting (err=-122)
Fri Mar 27 01:56:35 2026 kern.info kernel: [178948.519497] wlan-sta0: cannot understand ECSA IE operating class, 12, ignoring
Fri Mar 27 01:56:35 2026 daemon.notice netifd: Network device 'wlan-sta0' link is down
Fri Mar 27 01:56:35 2026 daemon.notice netifd: Interface 'wwan' has link connectivity loss
Fri Mar 27 01:56:35 2026 daemon.notice wpa_supplicant[2047]: wlan-sta0: CTRL-EVENT-DISCONNECTED bssid=20:xx:xx:xx:xx:aa reason=4 locally_generated=1
Fri Mar 27 01:56:35 2026 daemon.info lua: (...repeater:548) <3>CTRL-EVENT-DISCONNECTED bssid=20:xx:xx:xx:xx:aa reason=4 locally_generated=1
Fri Mar 27 01:56:35 2026 daemon.info lua: (...repeater:548) <3>CTRL-EVENT-SCAN-STARTED
Fri Mar 27 01:56:35 2026 daemon.err lua: (...repeater:1270) disconnected, wait reconnect...

Successful reconnection within a short time:

Fri Mar 27 01:56:36 2026 daemon.notice wpa_supplicant[2047]: wlan-sta0: SME: Trying to authenticate with 20:xx:xx:xx:xx:aa (SSID='HUAWEI-B528-6AAA' freq=2447 MHz)
Fri Mar 27 01:56:36 2026 daemon.info lua: (...repeater:548) <3>SME: Trying to authenticate with 20:xx:xx:xx:xx:aa (SSID='HUAWEI-B528-6AAA' freq=2447 MHz)
Fri Mar 27 01:56:36 2026 kern.info kernel: [178949.695643] wlan-sta0: authenticate with 20:xx:xx:xx:xx:aa
Fri Mar 27 01:56:36 2026 kern.info kernel: [178949.715080] wlan-sta0: send auth to 20:xx:xx:xx:xx:aa (try 1/3)
Fri Mar 27 01:56:36 2026 kern.info kernel: [178949.736237] wlan-sta0: authenticated
Fri Mar 27 01:56:36 2026 daemon.notice wpa_supplicant[2047]: wlan-sta0: Trying to associate with 20:xx:xx:xx:xx:aa (SSID='HUAWEI-B528-6AAA' freq=2447 MHz)
Fri Mar 27 01:56:36 2026 daemon.info lua: (...repeater:548) <3>Trying to associate with 20:xx:xx:xx:xx:aa (SSID='HUAWEI-B528-6AAA' freq=2447 MHz)
Fri Mar 27 01:56:36 2026 kern.info kernel: [178949.804664] wlan-sta0: associate with 20:xx:xx:xx:xx:aa (try 1/3)
Fri Mar 27 01:56:36 2026 kern.info kernel: [178949.815129] wlan-sta0: RX AssocResp from 20:xx:xx:xx:xx:aa (capab=0x1411 status=0 aid=1)
Fri Mar 27 01:56:36 2026 kern.info kernel: [178949.823831] wlan-sta0: associated
Fri Mar 27 01:56:36 2026 daemon.notice netifd: Network device 'wlan-sta0' link is up
Fri Mar 27 01:56:36 2026 daemon.notice netifd: Interface 'wwan' has link connectivity
Fri Mar 27 01:56:36 2026 daemon.notice wpa_supplicant[2047]: wlan-sta0: Associated with 20:xx:xx:xx:xx:aa
Fri Mar 27 01:56:36 2026 daemon.info lua: (...repeater:548) <3>Associated with 20:xx:xx:xx:xx:aa
Fri Mar 27 01:56:36 2026 daemon.notice wpa_supplicant[2047]: wlan-sta0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
Fri Mar 27 01:56:36 2026 daemon.info lua: (...repeater:548) <3>CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
Fri Mar 27 01:56:36 2026 daemon.notice wpa_supplicant[2047]: wlan-sta0: WPA: Key negotiation completed with 20:xx:xx:xx:xx:aa [PTK=CCMP GTK=CCMP]
Fri Mar 27 01:56:36 2026 daemon.info lua: (...repeater:548) <3>WPA: Key negotiation completed with 20:xx:xx:xx:xx:aa [PTK=CCMP GTK=CCMP]
Fri Mar 27 01:56:36 2026 daemon.notice wpa_supplicant[2047]: wlan-sta0: CTRL-EVENT-CONNECTED - Connection to 20:xx:xx:xx:xx:aa completed [id=0 id_str=]
Fri Mar 27 01:56:36 2026 daemon.info lua: (...repeater:548) <3>CTRL-EVENT-CONNECTED - Connection to 20:xx:xx:xx:xx:aa completed [id=0 id_str=]
Fri Mar 27 01:56:37 2026 daemon.notice netifd: Network device 'wlan0' link is up
Fri Mar 27 01:56:38 2026 daemon.info lua: (...repeater:1239) connected to 'HUAWEI-B528-6AAA(20:xx:xx:xx:xx:aa)' channel: 8, spent 3s

2. Due to poor signal quality or significant interference, the connection was lost. The device attempted to reconnect but initially timed out, then successfully reconnected after a short delay.

Disconnection caused by weak signal / heavy interference (beacon loss):

Fri Mar 27 02:51:42 2026 daemon.notice wpa_supplicant[2047]: wlan-sta0: CTRL-EVENT-BEACON-LOSS
Fri Mar 27 02:51:42 2026 daemon.info lua: (...repeater:548) <3>CTRL-EVENT-BEACON-LOSS
Fri Mar 27 02:51:42 2026 daemon.notice netifd: Network device 'wlan-sta0' link is down
Fri Mar 27 02:51:42 2026 daemon.notice netifd: Interface 'wwan' has link connectivity loss

Reconnection attempt (timeout):

Fri Mar 27 02:51:43 2026 daemon.notice wpa_supplicant[2047]: wlan-sta0: SME: Trying to authenticate with 20:xx:xx:xx:xx:aa (SSID='HUAWEI-B528-6AAA' freq=2447 MHz)
Fri Mar 27 02:51:43 2026 daemon.info lua: (...repeater:548) <3>SME: Trying to authenticate with 20:xx:xx:xx:xx:aa (SSID='HUAWEI-B528-6AAA' freq=2447 MHz)
Fri Mar 27 02:51:43 2026 kern.info kernel: [182256.931144] wlan-sta0: authenticate with 20:xx:xx:xx:xx:aa
Fri Mar 27 02:51:43 2026 kern.info kernel: [182256.950596] wlan-sta0: send auth to 20:xx:xx:xx:xx:aa (try 1/3)
Fri Mar 27 02:51:44 2026 user.notice mwan3[31599]: Execute ifdown event on interface wwan (unknown)
Fri Mar 27 02:51:44 2026 daemon.err lua: (...repeater:1270) disconnected, wait reconnect...
Fri Mar 27 02:51:44 2026 daemon.notice netifd: Interface 'wwan' is disabled
Fri Mar 27 02:51:44 2026 kern.info kernel: [182257.506873] wlan-sta0: send auth to 20:xx:xx:xx:xx:aa (try 2/3)
Fri Mar 27 02:51:44 2026 kern.info kernel: [182257.617758] wlan-sta0: send auth to 20:xx:xx:xx:xx:aa (try 3/3)
Fri Mar 27 02:51:44 2026 kern.info kernel: [182257.702231] wlan-sta0: authentication with 20:xx:xx:xx:xx:aa timed out

Reconnect after delay (successful):

Fri Mar 27 02:53:14 2026 daemon.notice wpa_supplicant[2047]: wlan-sta0: SME: Trying to authenticate with 20:xx:xx:xx:xx:aa (SSID='HUAWEI-B528-6AAA' freq=2442 MHz)
Fri Mar 27 02:53:14 2026 daemon.info lua: (...repeater:548) <3>SME: Trying to authenticate with 20:xx:xx:xx:xx:aa (SSID='HUAWEI-B528-6AAA' freq=2442 MHz)
Fri Mar 27 02:53:14 2026 kern.info kernel: [182347.411283] wlan-sta0: authenticate with 20:xx:xx:xx:xx:aa
Fri Mar 27 02:53:14 2026 kern.info kernel: [182347.430803] wlan-sta0: send auth to 20:xx:xx:xx:xx:aa (try 1/3)
Fri Mar 27 02:53:14 2026 daemon.notice wpa_supplicant[2047]: wlan-sta0: Trying to associate with 20:xx:xx:xx:xx:aa (SSID='HUAWEI-B528-6AAA' freq=2442 MHz)
Fri Mar 27 02:53:14 2026 daemon.info lua: (...repeater:548) <3>Trying to associate with 20:xx:xx:xx:xx:aa (SSID='HUAWEI-B528-6AAA' freq=2442 MHz)
Fri Mar 27 02:53:14 2026 kern.info kernel: [182347.439872] wlan-sta0: authenticated
Fri Mar 27 02:53:14 2026 kern.info kernel: [182347.456448] wlan-sta0: associate with 20:xx:xx:xx:xx:aa (try 1/3)
Fri Mar 27 02:53:14 2026 kern.info kernel: [182347.466922] wlan-sta0: RX AssocResp from 20:xx:xx:xx:xx:aa (capab=0x1411 status=0 aid=4)
Fri Mar 27 02:53:14 2026 kern.info kernel: [182347.475754] wlan-sta0: associated
Fri Mar 27 02:53:14 2026 daemon.notice netifd: Network device 'wlan-sta0' link is up
Fri Mar 27 02:53:14 2026 daemon.notice netifd: Interface 'wwan' has link connectivity
Fri Mar 27 02:53:14 2026 daemon.notice wpa_supplicant[2047]: wlan-sta0: Associated with 20:xx:xx:xx:xx:aa
Fri Mar 27 02:53:14 2026 daemon.info lua: (...repeater:548) <3>Associated with 20:xx:xx:xx:xx:aa
Fri Mar 27 02:53:14 2026 daemon.notice wpa_supplicant[2047]: wlan-sta0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
Fri Mar 27 02:53:14 2026 daemon.info lua: (...repeater:548) <3>CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
Fri Mar 27 02:53:14 2026 daemon.notice wpa_supplicant[2047]: wlan-sta0: WPA: Key negotiation completed with 20:xx:xx:xx:xx:aa [PTK=CCMP GTK=CCMP]
Fri Mar 27 02:53:14 2026 daemon.info lua: (...repeater:548) <3>WPA: Key negotiation completed with 20:xx:xx:xx:xx:aa [PTK=CCMP GTK=CCMP]
Fri Mar 27 02:53:14 2026 daemon.notice wpa_supplicant[2047]: wlan-sta0: CTRL-EVENT-CONNECTED - Connection to 20:xx:xx:xx:xx:aa completed [id=0 id_str=]
Fri Mar 27 02:53:14 2026 daemon.info lua: (...repeater:548) <3>CTRL-EVENT-CONNECTED - Connection to 20:xx:xx:xx:xx:aa completed [id=0 id_str=]
Fri Mar 27 02:53:14 2026 kern.info kernel: [182347.809355] br-lan: port 2(wlan0) entered blocking state
Fri Mar 27 02:53:14 2026 kern.info kernel: [182347.814954] br-lan: port 2(wlan0) entered forwarding state
Fri Mar 27 02:53:14 2026 daemon.notice netifd: Network device 'wlan0' link is up
Fri Mar 27 02:53:14 2026 daemon.info lua: (...repeater:1239) connected to 'HUAWEI-B528-6AAA(20:xx:xx:xx:xx:aa)' channel: 7, spent 2s

Based on this, we can draw the following preliminary conclusions:

The wireless disconnections on the AR300M are caused by poor signal conditions and external interference (including AP channel switching).
The AR300M itself is functioning normally—it continues attempting to reconnect after a drop and is able to successfully re-establish the connection.

We recommend that you:

Check the current wireless environment where the AR300M is located
Try moving the AR300M closer to the upstream AP to improve signal quality

will.qiu · March 30, 2026, 6:44am

Based on our analysis of the logs, we can confirm that the issue OP is experiencing is different from yours.

In OP’s case, the AR300M is able to automatically reconnect without any manual intervention.

WonTon79 · March 30, 2026, 9:25am

Hi will,

OK, so what is actually happening here then?

I’ve been blaming the WiFi as when I connect to the AR300M it shows as the WiFi being disconnected.
The logs show it as being connected apparently.

As I said, it it’s impossible to reach any devices on that network. It’s in that state again this morning.

If you look at the logs I sent, when I connected my laptop over WiFi (some time after 8AM) that fixed the connection and all the devices where accessible again.

When I log in, on the AR300M it shows the WiFi as disconnected and it reconnects again shortly.

This is all being done through wiregaurd, is it some sort of wiregaurd routing issue maybe?

I can tell you that restarting the wiregaurd server has no effect. The devices are still unreachable.

It’s in the same state again this morning. Devices unreachable. I need to go over, connect my laptop to the AR300M access point, disconnect, and it will be fixed. A power cycle won’t fix it.

will.qiu · April 1, 2026, 9:14am

As mentioned earlier, the AR300M is unable to maintain a stable connection to the upstream AP due to external factors.

The logs also show that in some cases, even when the Wi-Fi connection remains established, ping checks fail—indicating very poor link quality.

Fri Mar 27 02:53:18 2026 user.info mwan3track[1231]: Lost 50 ping(s) on interface wwan (wlan-sta0)

This offline issue is unrelated to WireGuard; it is caused by WAN-side network instability.

After several failed connection attempts, the AR300M enters a 30-second wait period before trying again. This is to avoid continuously overwhelming the upstream AP and to prevent frequent disruptions for devices connected to the AR300M due to repeated scanning and reconnection.

Fri Mar 27 02:52:05 2026 daemon.err lua: (...db/ipkg-mips_24kc/gl-sdk4-repeater/usr/sbin/repeater:1315) connect fail
Fri Mar 27 02:52:05 2026 daemon.err lua: (...db/ipkg-mips_24kc/gl-sdk4-repeater/usr/sbin/repeater:1318) reconnect in 30 seconds...

Therefore, if you access the AR300M while it is in this waiting phase, you can manually disconnect and trigger a reconnection. This does not mean the AR300M won’t automatically reconnect afterward.

WonTon79 · April 1, 2026, 9:49am

I feel like I may not be explaining this situation clearly.

The devices connected to that AR300M become unaccessible.

I’m, not talking for 30 seconds here. It will break and will not resolve itself. I can leave it for a week and it will not fix itself. Even a power cycle will not fix it.

If I go to the unit, connect my laptop to the AR300M, and then disconnect the laptop from the AR300M, it magically starts working again and units on that network are accessable remotely.

Something about connecting the laptop to the AR300M via WiFi is giving something on the AR300M a kick that it needs to start working again.

The only soloution I can see would be to have a device that randomly connects to the AR300M via WiFi to see if that fixes the connection, but that’s obviously a silly thing to try and have to implment.

will.qiu · April 1, 2026, 9:53am

Could you please clarify the following:

How is this device connected to the AR300M?
How are you accessing this device—through a WireGuard tunnel?
If so, when the issue occurs, are you still able to access the AR300M’s admin panel via WireGuard?

WonTon79 · April 1, 2026, 3:01pm

The LAN port.
Yes.
No, but the device is on port 80, so I wouldn’t be able to anyway.

Thanks.

will.qiu · April 3, 2026, 10:38am

At the moment, this issue seems somewhat difficult to diagnose, as the logs don’t appear to contain any related information, and the device is deployed remotely in a network environment that makes access challenging.

Would it be possible, the next time the problem occurs, to visit the site and connect to the device via a wired connection (which shouldn’t disrupt the router’s fault state), and then provide us remote access through AnyDesk?

Our availability is 9:30–12:30 and 14:30–18:30 (UTC+8) on weekdays (please note we will be on a public holiday from 4/6 to 4/7).
Please let us know if this works for you and your availability.

will.qiu · April 9, 2026, 7:32am

There may have been some misunderstanding. The request for remote access via AnyDesk was intended for the WonTon79’s issue, not yours.

At the moment, these appear to be two different issues. For your case, the logs contain relevant information, we have been able to reproduce it locally, and a beta firmware has already been provided for you to verify the fix.