GL-AR750 drops 5G connection - router mode, 5G WAN

I have a GL-AR750S and my WLAN sometimes drops when running both WWAN and WLAN on 5GHz. This happens more when there is higher traffic from downloading. The router does not actually freeze, nor reboot and I am able to manually reconnect WLAN again.

It is more stable when WWAN and WLAN are on different bands. Since it is only a travel router for me, I can live with that.

I am on firmware 3.211 and using 5G to repeat and broadcast wifi. It works OK. I wonder if you can reset your firmware and just try again?

Thanks - same issues as I have but using 2.4G as the wan is not an option for me.

@alzhao

Hi, I upgraded again to the latest firmware and have the same results.

Before upgrade things work with 5G WAN and 5G local client.

Upgrade, with 5G WAN then connect with 5G local client. Then run speed test. Download is good and fast, during upload 5G WAN and LAN connections drop.

Try to connect to 5G LAN again and sometimes works with either no or very slow 5G wan connection. **Update - the 5G lan comes back up after crashing but the WAN does not.

Log files attached.

I have reset to default many times, this does not help.

I will need to downgrade again to make the router usable with 5G WAN.

system log.zip (14.3 KB)

Just to avoid delays… log files with exact same disconnect results after a full reset and re-configuration of the router are attached.

system log after reset.zip (10.7 KB)

@alzhao Any thoughts on the log files please?

I can replicate this issue at any time at different locations with different host networks.

ON 14:23 it was broken and reconnected 14:25.

It was broken because there is udhcpc renew failure. If the main router is your own router, can you set the dhcp lease time longer? Now it is 2 hours. The router will renew every per hour.

@alzhao did you see the same thing on both sets of log files? And - should the router not return to full speed once the IP Address is renewed?

This can’t bee a DHCP error as I have tried the same thing on four different networks - the failure happens immediately after connecting so there is no way the IP address could be timed out by the router.

Again - this failure can be recreated on any network, the 5G connection remains down after it drops, and it occurs right after the router is turned on. Also, why is this not a problem on the older firmware?

Please consider other causes, do you need more log files?

Hi @alzhao did a complete reset and reload of the firmware, also connected to a router with a much longer dhcp lease time.

As you can see i can recreate the issue on-demand within minutes of setting up a fresh router and while connecting to any 5G host wifi connection.

New log files attached, you will notice the WAN crash at ~15:37.

Process is the same:

  1. reset router and reload fresh firmware
  2. connect to router and connect to 5G WAN
  3. update plugins, load luci, set time
  4. connect to router with 5G wireless client
  5. run speed test
  6. WAN dropped when upload test starts.

Please see log files again. Interesting to see the same feedback on Amazon reviews now.

logs with 4 hour dhcp wan fresh load.zip (18.3 KB)

Recreated again on a different host WAN

Mon Jan 31 17:59:16 2022 kern.info kernel: [ 268.220233] br-lan: port 2(wlan0) entered disabled state
Mon Jan 31 17:59:16 2022 kern.info kernel: [ 268.229283] wlan-sta: deauthenticating from 00:31:92:eb:f4:17 by local choice (Reason: 3=DEAUTH_LEAVING)
Mon Jan 31 17:59:16 2022 daemon.notice netifd: Network device ‘wlan-sta’ link is down
Mon Jan 31 17:59:16 2022 daemon.notice netifd: Interface ‘wwan’ has link connectivity loss
Mon Jan 31 17:59:16 2022 daemon.notice wpa_supplicant[6573]: wlan-sta: CTRL-EVENT-DISCONNECTED bssid=00:31:92:eb:f4:17 reason=3 locally_generated=1
Mon Jan 31 17:59:16 2022 daemon.notice wpa_supplicant[6573]: wlan-sta: PMKSA-CACHE-REMOVED 00:31:92:eb:f4:17 0
Mon Jan 31 17:59:16 2022 daemon.notice netifd: wwan (6672): udhcpc: received SIGTERM
Mon Jan 31 17:59:16 2022 daemon.notice netifd: Interface ‘wwan’ is now down
Mon Jan 31 17:59:16 2022 daemon.notice netifd: Interface ‘wwan’ is disabled
Mon Jan 31 17:59:16 2022 daemon.notice netifd: Interface ‘wwan’ is enabled
Mon Jan 31 17:59:16 2022 daemon.warn dnsmasq[2757]: no servers found in /tmp/resolv.conf.auto, will retry
Mon Jan 31 17:59:19 2022 daemon.notice netifd: Network device ‘wlan0’ link is up
Mon Jan 31 17:59:19 2022 kern.info kernel: [ 271.510668] br-lan: port 2(wlan0) entered blocking state
Mon Jan 31 17:59:19 2022 kern.info kernel: [ 271.516232] br-lan: port 2(wlan0) entered forwarding state

@alzhao your feedback please on additional log files and examples.

It is Chinese New Year holidays.

1 Like

Thanks for the detailed report. I did test using AR750 and 3.211 today and I can replicate this problem.

I think this is related to the encryption the upstream router using.

My upstream router is using wpa3 and I have this problem. When I set upstream router to wpa2 it works OK. Is this your case?

I filed a bug internally about this.

1 Like

Hi, Thanks so much for confirming and for filing a bug report. Hopefully it’s an easy fix :).

I forced my upstream router to WPA2 but the AR750 still crashed. The trigger seems to be a larger upload so I can force the bug on-demand by running a speedtest. The download works perfect, but the upload test crashes the router.

Thanks again, looks like the fix for now is to use the older firmware.

:+1:

I saw this. But let just wait for our developers to test and fix.

1 Like

Sorry for late reply. The bug was fixed in firmware 3.212. Snapshot firmware is available.

https://dl.gl-inet.com/?model=ar750&type=snapshot

2 Likes

Thanks, testing it now and will continue to do so for a few days.

So far so good although the speed drop from the host router is more than expected.

Thanks again!

Is this same bug in the AR750s firmware? I am on travel and was running firmware 3.203 on a AR750s, and was seeing a similar issue where my router was dropping out for over a minute at a time multiple times each day, and I could easily trigger the problem by running librespeed.org speed test on my PC and the router would dropout during the upload phase of the test. In my case, I was using 2.4G as my WAN connection, and 5G for connecting to my devices. The router I am connecting my AR750s to is a an older router that is using WPA2, and I have no control or visibility into this router.

During this same time I also experienced several occurrences of out-of memory errors on my router while using Wireguard, which required me to reboot the AR750s to clear the issue. I had to configure my AR750S to use OpenVPN to work around this issue. The out of memory error report looked like this:

[24718.981235] Out of memory: Kill process 3202 (lighttpd) score 7 or sacrifice child
[24718.989070] Killed process 3203 (api) total-vm:3236kB, anon-rss:148kB, file-rss:4kB, shmem-rss:0kB
[24718.998521] ath10k_pci 0000:00:00.0: SWBA overrun on vdev 0, skipped old beacon
[24719.006082] ath10k_pci 0000:00:00.0: SWBA overrun on vdev 0, skipped old beacon
[24720.109229] oom_reaper: reaped process 3203 (api), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
[24720.118706] gl_health invoked oom-killer: gfp_mask=0x14201ca(GFP_HIGHUSER_MOVABLE|__GFP_COLD), nodemask=(null),  order=0, oom_score_adj=0

The problems became so bad that I stopped using the AR750s, and just ran Wireguard on my phone, tablet and PC, as while I am on travel, I just don’t have time to debug faulty router firmware. All my devices network connections were very stable while running without the AR750s, so I am assuming the router in the building was not the cause of my problems.

Yesterday I had some down time and installed 3.212 beta1 on the AR750s, without saving my configuration, and the routers seems much more stable. I am still connecting to the same router and I have been able to run the speed test many times, and even tested uploads by uploading a couple multi-gigabyte files, without seeing the router lockup. Also, I have not seen the out-of-memory issues while using Wireguard with the new firmware.

What I am looking for is confirmation that this bug or a similar bug was in the AR750s 3.203 firmware and is fixed in 3.212.

Just an FYI on the 3.212 firmware. I was not able to see if there were any issues for all of last night, as the log-buffer rolled over, as there are over 700 lines of the following error listed when I ran logread this morning:

Sun Mar  6 06:42:25 2022 daemon.notice wpa_supplicant[7178]: wlan-sta: CTRL-EVENT-BEACON-LOSS
Sun Mar  6 06:42:26 2022 daemon.notice wpa_supplicant[7178]: wlan-sta: CTRL-EVENT-BEACON-LOSS
Sun Mar  6 06:42:29 2022 daemon.notice wpa_supplicant[7178]: wlan-sta: CTRL-EVENT-BEACON-LOSS
Sun Mar  6 06:42:30 2022 daemon.notice wpa_supplicant[7178]: wlan-sta: CTRL-EVENT-BEACON-LOSS
Sun Mar  6 06:42:33 2022 daemon.notice wpa_supplicant[7178]: wlan-sta: CTRL-EVENT-BEACON-LOSS
Sun Mar  6 06:42:34 2022 daemon.notice wpa_supplicant[7178]: wlan-sta: CTRL-EVENT-BEACON-LOSS
Sun Mar  6 06:42:46 2022 daemon.notice wpa_supplicant[7178]: wlan-sta: CTRL-EVENT-BEACON-LOSS
Sun Mar  6 06:45:07 2022 daemon.notice wpa_supplicant[7178]: wlan-sta: CTRL-EVENT-BEACON-LOSS
Sun Mar  6 06:45:08 2022 daemon.notice wpa_supplicant[7178]: wlan-sta: CTRL-EVENT-BEACON-LOSS
Sun Mar  6 06:45:20 2022 daemon.notice wpa_supplicant[7178]: wlan-sta: CTRL-EVENT-BEACON-LOSS
Sun Mar  6 06:45:25 2022 daemon.notice wpa_supplicant[7178]: wlan-sta: CTRL-EVENT-BEACON-LOSS
Sun Mar  6 06:46:09 2022 daemon.notice wpa_supplicant[7178]: wlan-sta: CTRL-EVENT-BEACON-LOSS
Sun Mar  6 06:47:03 2022 daemon.notice wpa_supplicant[7178]: wlan-sta: CTRL-EVENT-BEACON-LOSS
Sun Mar  6 06:47:50 2022 daemon.notice wpa_supplicant[7178]: wlan-sta: CTRL-EVENT-BEACON-LOSS
Sun Mar  6 06:48:48 2022 daemon.notice wpa_supplicant[7178]: wlan-sta: CTRL-EVENT-BEACON-LOSS
Sun Mar  6 06:48:53 2022 daemon.notice wpa_supplicant[7178]: wlan-sta: CTRL-EVENT-BEACON-LOSS
Sun Mar  6 06:50:05 2022 daemon.notice wpa_supplicant[7178]: wlan-sta: CTRL-EVENT-BEACON-LOSS
Sun Mar  6 06:50:39 2022 daemon.notice wpa_supplicant[7178]: wlan-sta: CTRL-EVENT-BEACON-LOSS
Sun Mar  6 06:51:25 2022 daemon.notice wpa_supplicant[7178]: wlan-sta: CTRL-EVENT-BEACON-LOSS
Sun Mar  6 06:51:31 2022 daemon.notice wpa_supplicant[7178]: wlan-sta: CTRL-EVENT-BEACON-LOSS

Yes this same error should happen on AR750s as well, although I didn’t verify.

Last update…

I’ve tested the latest beta and snapshot firmware at two hotels and off my own test network at home.

It’s sold - even ran a constant 1080HD youtube stream for two days solid without any drop offs or problems with me doing work on my laptop or streaming TV at the same time.

Good stuff - Thanks!

2 Likes