GL-MT1300 LAN WiFi Constantly drops out

I have a GL-MT1300 running a WireGuard client. It is connected to either a wireless AP, LAN or USB tethering. With any of the three WAN connections the LAN devices will regularly disconnect from the GL-MT1300’s wireless network. It seems like the Wireless network goes down about every 5 minutes for 20 seconds or so.

When I factor reset it stops happening for a day or two and then continues to happen.

This happens with both 2.4GHz and 5GHz with WPA2 and WPA3. I’m running the
3.201 firmware but it also happened with the previous firmware version.

Besides the wireless LAN options, WireGuard client, DNS rebinding and DNS over TLS I haven’t made any changes to the default settings.

As a new user I can’t attach the kernel log (uploads and copying it don’t work). The last few lines look like this though

[ 1086.342182] WextMboSendStaDisassocToDaemonEvent [18:cf:5e:fc:75:d3] sizeof 6 					report_buf_len 6 buflen 180 msg_type MBO_MSG_REMOVE_STA
[ 1091.208615] AP SETKEYS DONE - AKMMap=WPA2PSK, PairwiseCipher=AES, GroupCipher=AES, wcid=1 from 18:CF:5E:FC:75:D3
[ 1091.208615] 
[ 1123.336262] scan_ch_restore,central ch=42,bw=2
[ 1123.336262] 
[ 1127.111874] scan_ch_restore,central ch=1,bw=0
[ 1127.111874] 
[ 1131.380779] WextMboSendStaDisassocToDaemonEvent [18:cf:5e:fc:75:d3] sizeof 6 					report_buf_len 6 buflen 180 msg_type MBO_MSG_REMOVE_STA
[ 1135.305474] AP SETKEYS DONE - AKMMap=WPA2PSK, PairwiseCipher=AES, GroupCipher=AES, wcid=1 from 18:CF:5E:FC:75:D3
[ 1135.305474] 
[ 1168.461950] scan_ch_restore,central ch=42,bw=2
[ 1168.461950] 
[ 1172.250745] scan_ch_restore,central ch=1,bw=0
[ 1172.250745] 
[ 1176.339458] WextMboSendStaDisassocToDaemonEvent [18:cf:5e:fc:75:d3] sizeof 6 					report_buf_len 6 buflen 180 msg_type MBO_MSG_REMOVE_STA
[ 1180.265164] AP SETKEYS DONE - AKMMap=WPA2PSK, PairwiseCipher=AES, GroupCipher=AES, wcid=1 from 18:CF:5E:FC:75:D3
[ 1180.265164] 
[ 1213.613628] scan_ch_restore,central ch=42,bw=2
[ 1213.613628] 
[ 1217.389299] scan_ch_restore,central ch=1,bw=0
[ 1217.389299] 
[ 1221.218199] WextMboSendStaDisassocToDaemonEvent [18:cf:5e:fc:75:d3] sizeof 6 					report_buf_len 6 buflen 180 msg_type MBO_MSG_REMOVE_STA
[ 1226.066962] AP SETKEYS DONE - AKMMap=WPA2PSK, PairwiseCipher=AES, GroupCipher=AES, wcid=1 from 18:CF:5E:FC:75:D3
[ 1226.066962] 
[ 1258.076862] scan_ch_restore,central ch=42,bw=2
[ 1258.076862] 
[ 1261.750377] WextMboSendStaDisassocToDaemonEvent [18:cf:5e:fc:75:d3] sizeof 6 					report_buf_len 6 buflen 180 msg_type MBO_MSG_REMOVE_STA
[ 1262.399097] scan_ch_restore,central ch=1,bw=0
[ 1262.399097] 
[ 1262.982267] AP SETKEYS DONE - AKMMap=WPA2PSK, PairwiseCipher=AES, GroupCipher=AES, wcid=1 from 18:CF:5E:FC:75:D3
[ 1262.982267] 
[ 1303.790992] scan_ch_restore,central ch=42,bw=2
[ 1303.790992] 
[ 1306.175549] WextMboSendStaDisassocToDaemonEvent [18:cf:5e:fc:75:d3] sizeof 6 					report_buf_len 6 buflen 180 msg_type MBO_MSG_REMOVE_STA
[ 1310.210210] AP SETKEYS DONE - AKMMap=WPA2PSK, PairwiseCipher=AES, GroupCipher=AES, wcid=1 from 18:CF:5E:FC:75:D3
[ 1310.210210]

Can you get the system log, not kernel?

Maybe you can try putting your log on the server e.g. this one https://cloudvyzor.com/

The latest system log is available at: https://paste.c-net.org/ShrinksAching

I’ll try and see if I can get some more logs tomorrow when it drops out.

This seems to be the system log when a drop out happens

Tue Jun  8 08:59:10 2021 daemon.info dnsmasq-dhcp[681]: DHCPREQUEST(br-lan) 192.168.8.230 e6:29:7b:c8:87:5f
Tue Jun  8 08:59:10 2021 daemon.info dnsmasq-dhcp[681]: DHCPACK(br-lan) 192.168.8.230 e6:29:7b:c8:87:5f
Tue Jun  8 08:59:14 2021 kern.warn kernel: [45607.969866] AP SETKEYS DONE - AKMMap=WPA2PSK, PairwiseCipher=AES, GroupCipher=AES, wcid=2 from 0C:7A:15:8D:B3:55
Tue Jun  8 08:59:14 2021 kern.warn kernel: [45607.969866]
Tue Jun  8 08:59:14 2021 daemon.info dnsmasq-dhcp[681]: DHCPREQUEST(br-lan) 192.168.8.168 0c:7a:15:8d:b3:55
Tue Jun  8 08:59:14 2021 daemon.info dnsmasq-dhcp[681]: DHCPACK(br-lan) 192.168.8.168 0c:7a:15:8d:b3:55 DESKTOP-7C1SIO1
Tue Jun  8 08:59:20 2021 kern.warn kernel: [45614.148794] AP SETKEYS DONE - AKMMap=WPA2PSK, PairwiseCipher=AES, GroupCipher=AES, wcid=3 from 18:CF:5E:FC:75:D3
Tue Jun  8 08:59:20 2021 kern.warn kernel: [45614.148794]
Tue Jun  8 08:59:20 2021 daemon.info dnsmasq-dhcp[681]: DHCPREQUEST(br-lan) 192.168.8.123 18:cf:5e:fc:75:d3
Tue Jun  8 08:59:20 2021 daemon.info dnsmasq-dhcp[681]: DHCPACK(br-lan) 192.168.8.123 18:cf:5e:fc:75:d3 risc6-librem
Tue Jun  8 08:59:49 2021 kern.warn kernel: [45643.114527] scan_ch_restore,central ch=42,bw=2
Tue Jun  8 08:59:49 2021 kern.warn kernel: [45643.114527]
Tue Jun  8 08:59:49 2021 kern.warn kernel: [45643.117873] WextMboSendStaDisassocToDaemonEvent [e6:29:7b:c8:87:5f] sizeof 6 					report_buf_len 6 buflen 180 msg_type MBO_MSG_REMOVE_STA
Tue Jun  8 08:59:51 2021 kern.warn kernel: [45644.841805] WextMboSendStaDisassocToDaemonEvent [0c:7a:15:8d:b3:55] sizeof 6 					report_buf_len 6 buflen 180 msg_type MBO_MSG_REMOVE_STA
Tue Jun  8 08:59:52 2021 daemon.info dnsmasq-dhcp[681]: DHCPREQUEST(br-lan) 192.168.8.230 e6:29:7b:c8:87:5f
Tue Jun  8 08:59:52 2021 daemon.info dnsmasq-dhcp[681]: DHCPACK(br-lan) 192.168.8.230 e6:29:7b:c8:87:5f
Tue Jun  8 08:59:52 2021 kern.warn kernel: [45646.134812] scan_ch_restore,central ch=1,bw=0
Tue Jun  8 08:59:52 2021 kern.warn kernel: [45646.134812]
Tue Jun  8 08:59:52 2021 kern.warn kernel: [45646.145383] AP SETKEYS DONE - AKMMap=WPA2PSK, PairwiseCipher=AES, GroupCipher=AES, wcid=1 from E6:29:7B:C8:87:5F
Tue Jun  8 08:59:52 2021 kern.warn kernel: [45646.145383]
Tue Jun  8 08:59:53 2021 kern.warn kernel: [45647.161793] WextMboSendStaDisassocToDaemonEvent [18:cf:5e:fc:75:d3] sizeof 6 					report_buf_len 6 buflen 180 msg_type MBO_MSG_REMOVE_STA
Tue Jun  8 08:59:55 2021 kern.warn kernel: [45648.830421] AP SETKEYS DONE - AKMMap=WPA2PSK, PairwiseCipher=AES, GroupCipher=AES, wcid=2 from 18:CF:5E:FC:75:D3
Tue Jun  8 08:59:55 2021 kern.warn kernel: [45648.830421]
Tue Jun  8 08:59:56 2021 kern.warn kernel: [45649.757176] AP SETKEYS DONE - AKMMap=WPA2PSK, PairwiseCipher=AES, GroupCipher=AES, wcid=3 from 0C:7A:15:8D:B3:55
Tue Jun  8 08:59:56 2021 kern.warn kernel: [45649.757176]
Tue Jun  8 08:59:56 2021 daemon.info dnsmasq-dhcp[681]: DHCPREQUEST(br-lan) 192.168.8.168 0c:7a:15:8d:b3:55
Tue Jun  8 08:59:56 2021 daemon.info dnsmasq-dhcp[681]: DHCPACK(br-lan) 192.168.8.168 0c:7a:15:8d:b3:55 DESKTOP-7C1SIO1
Tue Jun  8 08:59:57 2021 daemon.info dnsmasq-dhcp[681]: DHCPDISCOVER(br-lan) 192.168.8.123 18:cf:5e:fc:75:d3
Tue Jun  8 08:59:57 2021 daemon.info dnsmasq-dhcp[681]: DHCPOFFER(br-lan) 192.168.8.123 18:cf:5e:fc:75:d3
Tue Jun  8 08:59:57 2021 daemon.info dnsmasq-dhcp[681]: DHCPREQUEST(br-lan) 192.168.8.123 18:cf:5e:fc:75:d3
Tue Jun  8 08:59:57 2021 daemon.info dnsmasq-dhcp[681]: DHCPACK(br-lan) 192.168.8.123 18:cf:5e:fc:75:d3 risc6-librem
Tue Jun  8 09:00:35 2021 kern.warn kernel: [45687.882603] scan_ch_restore,central ch=42,bw=2
Tue Jun  8 09:00:35 2021 kern.warn kernel: [45687.882603]
Tue Jun  8 09:00:35 2021 kern.warn kernel: [45689.479984] WextMboSendStaDisassocToDaemonEvent [e6:29:7b:c8:87:5f] sizeof 6 					report_buf_len 6 buflen 180 msg_type MBO_MSG_REMOVE_STA
Tue Jun  8 09:00:38 2021 kern.warn kernel: [45691.168094] scan_ch_restore,central ch=1,bw=0
Tue Jun  8 09:00:38 2021 kern.warn kernel: [45691.168094]
Tue Jun  8 09:00:38 2021 kern.warn kernel: [45691.639595] WextMboSendStaDisassocToDaemonEvent [0c:7a:15:8d:b3:55] sizeof 6 					report_buf_len 6 buflen 180 msg_type MBO_MSG_REMOVE_STA
Tue Jun  8 09:00:39 2021 daemon.info dnsmasq-dhcp[681]: DHCPREQUEST(br-lan) 192.168.8.168 0c:7a:15:8d:b3:55
Tue Jun  8 09:00:39 2021 daemon.info dnsmasq-dhcp[681]: DHCPACK(br-lan) 192.168.8.168 0c:7a:15:8d:b3:55 DESKTOP-7C1SIO1
Tue Jun  8 09:00:39 2021 kern.warn kernel: [45692.806249] AP SETKEYS DONE - AKMMap=WPA2PSK, PairwiseCipher=AES, GroupCipher=AES, wcid=1 from 0C:7A:15:8D:B3:55
Tue Jun  8 09:00:39 2021 kern.warn kernel: [45692.806249]
Tue Jun  8 09:00:40 2021 daemon.info dnsmasq-dhcp[681]: DHCPREQUEST(br-lan) 192.168.8.230 e6:29:7b:c8:87:5f
Tue Jun  8 09:00:40 2021 daemon.info dnsmasq-dhcp[681]: DHCPACK(br-lan) 192.168.8.230 e6:29:7b:c8:87:5f
Tue Jun  8 09:00:40 2021 kern.warn kernel: [45693.914964] AP SETKEYS DONE - AKMMap=WPA2PSK, PairwiseCipher=AES, GroupCipher=AES, wcid=3 from E6:29:7B:C8:87:5F
Tue Jun  8 09:00:40 2021 kern.warn kernel: [45693.914964]
Tue Jun  8 09:00:56 2021 daemon.info dnsmasq-dhcp[681]: DHCPREQUEST(br-lan) 192.168.8.228 00:23:81:34:ea:58
Tue Jun  8 09:00:56 2021 daemon.info dnsmasq-dhcp[681]: DHCPACK(br-lan) 192.168.8.228 00:23:81:34:ea:58 risc6-librem
Tue Jun  8 09:01:09 2021 kern.warn kernel: [45722.731215] WextMboSendStaDisassocToDaemonEvent [18:cf:5e:fc:75:d3] sizeof 6

From you log, seems that your client is continuously requesting dhcp

I’m guessing that’s because it is loosing and then re-joining the WiFi network

If it disconnected, then there will be other logs in between. Seems it is just requesting dhcp for some reason.

I have followed the logs a bit more and all devices, from different vendors running different OSes all have the same DHCP messages. So it seems that something is wrong on the GL-MT1300 which is causing this.

I did just see a

daemon.warn dnsmasq[4561]: possible DNS-rebind attack detected

any chance that’s related?

I don’t think this is related.

But you can go to more settings → custom dns and disable dns rebinding protection and check again?

Tried that, no luck. Still seeing disconnects

Any other ideas? Is it worth trying the 3.203 firmware?

I’m trying disabling DNS over TLS to see if that helps, but I don’t have high hopes. I’ll also test without Wireguard to see if that helps, but that isn’t a long term solution. Enabling/disabling Wireguard or DNS settings doesn’t seem to make any difference. I still see regular disconnects.

I have also now tried a 65W laptop USB charger to see if that helps, no luck. I lowered the 2.4GHz and 5Ghz power as well and no luck there.

Otherwise I’m going to have to return it. It doesn’t work as every device is constantly disconnected from the WiFi.

The only thing to check now is wifi encryption.

But if all devices disconnect, then is may be something else. If things cannot improve you may return.

Even if it is WiFi encryption, I’m not going to disable that. Who do I talk to about a refund?

1 Like

On a Linux system this is the type of errors that I see:

[ 2410.023392] net_ratelimit: 10 callbacks suppressed
[ 2410.023398] iwlwifi 0000:45:00.0: Unhandled alg: 0x3f0707
[ 2410.024037] iwlwifi 0000:45:00.0: Unhandled alg: 0x3f0707
[ 2410.024744] iwlwifi 0000:45:00.0: Unhandled alg: 0x3f0707
[ 2410.027082] iwlwifi 0000:45:00.0: Unhandled alg: 0x3f0707
[ 2410.027083] iwlwifi 0000:45:00.0: Unhandled alg: 0x3f0707
[ 2410.027084] iwlwifi 0000:45:00.0: Unhandled alg: 0x3f0707
[ 2410.029444] iwlwifi 0000:45:00.0: Unhandled alg: 0x3f0707
[ 2410.029446] iwlwifi 0000:45:00.0: Unhandled alg: 0x3f0707
[ 2410.029447] iwlwifi 0000:45:00.0: Unhandled alg: 0x3f0707
[ 2410.030063] iwlwifi 0000:45:00.0: Unhandled alg: 0x3f0707
[ 2445.697804] wlp69s0: authenticate with 94:83:c4:0d:50:14
[ 2445.700177] wlp69s0: send auth to 94:83:c4:0d:50:14 (try 1/3)
[ 2445.735420] wlp69s0: authenticated
[ 2445.735758] wlp69s0: associate with 94:83:c4:0d:50:14 (try 1/3)
[ 2445.749495] wlp69s0: RX AssocResp from 94:83:c4:0d:50:14 (capab=0x431 status=0 aid=4)
[ 2445.755792] wlp69s0: associated
[ 2451.428640] wlp69s0: authenticate with 94:83:c4:0d:50:14
[ 2451.430998] wlp69s0: send auth to 94:83:c4:0d:50:14 (try 1/3)
[ 2451.460982] wlp69s0: authenticated
[ 2451.461689] wlp69s0: associate with 94:83:c4:0d:50:14 (try 1/3)
[ 2451.467240] wlp69s0: RX AssocResp from 94:83:c4:0d:50:14 (capab=0x431 status=0 aid=4)
[ 2451.471388] wlp69s0: associated
[ 2491.196941] wlp69s0: authenticate with 94:83:c4:0d:50:14
[ 2491.199312] wlp69s0: send auth to 94:83:c4:0d:50:14 (try 1/3)
[ 2491.228243] wlp69s0: authenticated
[ 2491.230228] wlp69s0: associate with 94:83:c4:0d:50:14 (try 1/3)
[ 2491.237882] wlp69s0: RX AssocResp from 94:83:c4:0d:50:14 (capab=0x431 status=0 aid=4)
[ 2491.241714] wlp69s0: associated
[ 2494.653894] wlp69s0: authenticate with 94:83:c4:0d:50:14
[ 2494.656232] wlp69s0: send auth to 94:83:c4:0d:50:14 (try 1/3)
[ 2494.686114] wlp69s0: authenticated
[ 2494.688171] wlp69s0: associate with 94:83:c4:0d:50:14 (try 1/3)
[ 2494.693643] wlp69s0: RX AssocResp from 94:83:c4:0d:50:14 (capab=0x431 status=0 aid=4)
[ 2494.699910] wlp69s0: associated
[ 2494.786001] net_ratelimit: 12 callbacks suppressed
[ 2494.786006] iwlwifi 0000:45:00.0: Unhandled alg: 0x3f0707
[ 2538.118034] wlp69s0: authenticate with 94:83:c4:0d:50:14
[ 2538.120429] wlp69s0: send auth to 94:83:c4:0d:50:14 (try 1/3)
[ 2538.248114] wlp69s0: send auth to 94:83:c4:0d:50:14 (try 2/3)
[ 2538.350967] wlp69s0: send auth to 94:83:c4:0d:50:14 (try 3/3)
[ 2538.634613] wlp69s0: authentication with 94:83:c4:0d:50:14 timed out
[ 2545.316930] wlp69s0: authenticate with 94:83:c4:0d:50:14
[ 2545.319606] wlp69s0: send auth to 94:83:c4:0d:50:14 (try 1/3)
[ 2545.350196] wlp69s0: authenticated
[ 2545.350560] wlp69s0: associate with 94:83:c4:0d:50:14 (try 1/3)
[ 2545.359389] wlp69s0: RX AssocResp from 94:83:c4:0d:50:14 (capab=0x431 status=0 aid=4)
[ 2545.360932] iwlwifi 0000:45:00.0: Unhandled alg: 0x3f0707
[ 2545.362185] wlp69s0: associated

Can you get the log of wpa_supplicant from your Linux which could show more info?

It should be in /var/log/syslog

Jun 21 08:56:37 wpa_supplicant[4144]: dbus: wpa_dbus_property_changed: no property SessionLength in object /fi/w1/wpa_supplicant1/Interfac>
Jun 21 08:56:38 wpa_supplicant[4144]: wlp69s0: SME: Trying to authenticate with 94:83:c4:0d:50:14 (SSID=‘’ freq=2462 MHz)
Jun 21 08:56:38 wpa_supplicant[4144]: wlp69s0: Trying to associate with 94:83:c4:0d:50:14 (SSID='
’ freq=2462 MHz)
Jun 21 08:56:38 wpa_supplicant[4144]: wlp69s0: Associated with 94:83:c4:0d:50:14
Jun 21 08:56:38 wpa_supplicant[4144]: wlp69s0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
Jun 21 08:56:38 wpa_supplicant[4144]: wlp69s0: WPA: Key negotiation completed with 94:83:c4:0d:50:14 [PTK=CCMP GTK=CCMP]
Jun 21 08:56:38 wpa_supplicant[4144]: wlp69s0: CTRL-EVENT-CONNECTED - Connection to 94:83:c4:0d:50:14 completed [id=0 id_str=]
Jun 21 08:56:38 wpa_supplicant[4144]: wlp69s0: CTRL-EVENT-SIGNAL-CHANGE above=0 signal=-73 noise=9999 txrate=26000
Jun 21 08:56:40 wpa_supplicant[4144]: wlp69s0: CTRL-EVENT-BEACON-LOSS
Jun 21 08:56:41 wpa_supplicant[4144]: wlp69s0: CTRL-EVENT-BEACON-LOSS
Jun 21 08:56:41 wpa_supplicant[4144]: wlp69s0: CTRL-EVENT-BEACON-LOSS
Jun 21 08:56:41 wpa_supplicant[4144]: wlp69s0: CTRL-EVENT-DISCONNECTED bssid=94:83:c4:0d:50:14 reason=4 locally_generated=1
Jun 21 08:56:41 wpa_supplicant[4144]: dbus: wpa_dbus_property_changed: no property SessionLength in object /fi/w1/wpa_supplicant1/Interfac>
Jun 21 08:56:41 wpa_supplicant[4144]: wlp69s0: SME: Trying to authenticate with 94:83:c4:0d:50:14 (SSID=‘’ freq=2462 MHz)
Jun 21 08:56:41 wpa_supplicant[4144]: wlp69s0: Trying to associate with 94:83:c4:0d:50:14 (SSID='
’ freq=2462 MHz)
Jun 21 08:56:41 wpa_supplicant[4144]: wlp69s0: Associated with 94:83:c4:0d:50:14
Jun 21 08:56:41 wpa_supplicant[4144]: wlp69s0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
Jun 21 08:56:41 wpa_supplicant[4144]: wlp69s0: WPA: Key negotiation completed with 94:83:c4:0d:50:14 [PTK=CCMP GTK=CCMP]
Jun 21 08:56:41 wpa_supplicant[4144]: wlp69s0: CTRL-EVENT-CONNECTED - Connection to 94:83:c4:0d:50:14 completed [id=0 id_str=]
Jun 21 08:56:41 wpa_supplicant[4144]: wlp69s0: CTRL-EVENT-SIGNAL-CHANGE above=0 signal=-70 noise=9999 txrate=26000
Jun 21 08:57:22 wpa_supplicant[4144]: wlp69s0: CTRL-EVENT-BEACON-LOSS
Jun 21 08:57:22 wpa_supplicant[4144]: wlp69s0: CTRL-EVENT-BEACON-LOSS
Jun 21 08:57:22 wpa_supplicant[4144]: wlp69s0: CTRL-EVENT-BEACON-LOSS
Jun 21 08:57:22 wpa_supplicant[4144]: wlp69s0: CTRL-EVENT-BEACON-LOSS
Jun 21 08:57:26 wpa_supplicant[4144]: wlp69s0: CTRL-EVENT-BEACON-LOSS
Jun 21 08:57:26 wpa_supplicant[4144]: wlp69s0: CTRL-EVENT-BEACON-LOSS
Jun 21 08:57:26 wpa_supplicant[4144]: wlp69s0: CTRL-EVENT-BEACON-LOSS
Jun 21 08:57:26 wpa_supplicant[4144]: wlp69s0: CTRL-EVENT-DISCONNECTED bssid=94:83:c4:0d:50:14 reason=4 locally_generated=1

Use your mobile phone to connect to the MT1300, normal?

Nope, all devices appear to have the same problem

I had the same and I found that if a client makes an excessive number of DNS requests (reliably replicated - until i found the reason, I reimaged the router and configured from scratch again, though it was a problem with the router) the router drops the connection.

if on windows, try LiveTcpUdpWatch from nirsoft[.]net or other equivalent if mac etc

How did you solve then?