AR750S Constantly Disconnecting from Repeater Wifi

[SlothCroissant]

My AR750s constantly drops connection on repeater mode running latest v3.201. It’ll run for anywhere from a few mins to a few hours before bouncing and disconnecting for 30sec or a minute at least. “LAN” side connection has no issues whatsoever, but “WAN” drops hard.

When connecting to the source wireless directly (bypassing the AR750s), I see no disconnects at all.

I’ve tried with and without “auto-reconnect” (saw in a previous thread from 2019 that this could fix, but that was many FW versions ago, so didn’t resolve). I’ve also tried connecting to all combinations of 2G/5G (on both WAN and LAN side) - with no solution.

Logs:

Wed Apr 21 19:13:09 2021 daemon.notice netifd: Network device 'wlan1' link is down
Wed Apr 21 19:13:09 2021 kern.info kernel: [ 5709.536078] br-lan: port 3(wlan1) entered disabled state
Wed Apr 21 19:13:09 2021 kern.info kernel: [ 5709.545061] wlan-sta: deauthenticating from 54:83:3a:89:f0:79 by local choice (Reason: 3=DEAUTH_LEAVING)
Wed Apr 21 19:13:09 2021 daemon.notice netifd: Network device 'wlan-sta' link is down
Wed Apr 21 19:13:09 2021 daemon.notice netifd: Interface 'wwan' has link connectivity loss
Wed Apr 21 19:13:10 2021 daemon.notice netifd: wwan (2430): udhcpc: received SIGTERM
Wed Apr 21 19:13:10 2021 daemon.notice netifd: Interface 'wwan' is now down
Wed Apr 21 19:13:10 2021 daemon.notice wpa_supplicant[2345]: wlan-sta: CTRL-EVENT-DISCONNECTED bssid=54:83:3a:89:f0:79 reason=3 locally_generated=1
Wed Apr 21 19:13:10 2021 daemon.notice netifd: Interface 'wwan' is disabled
Wed Apr 21 19:13:10 2021 daemon.notice netifd: Interface 'wwan' is enabled
Wed Apr 21 19:13:11 2021 daemon.notice hostapd: handle_probe_req: send failed
Wed Apr 21 19:13:11 2021 daemon.notice hostapd: handle_probe_req: send failed
Wed Apr 21 19:13:11 2021 daemon.notice hostapd: handle_probe_req: send failed
Wed Apr 21 19:13:12 2021 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED c4:9d:ed:ae:75:4f
Wed Apr 21 19:13:12 2021 daemon.info hostapd: wlan1: STA c4:9d:ed:ae:75:4f IEEE 802.11: disassociated due to inactivity
Wed Apr 21 19:13:12 2021 daemon.notice hostapd: handle_probe_req: send failed
Wed Apr 21 19:13:12 2021 daemon.notice hostapd: handle_probe_req: send failed
Wed Apr 21 19:13:12 2021 daemon.notice hostapd: handle_probe_req: send failed
Wed Apr 21 19:13:12 2021 daemon.notice hostapd: handle_probe_req: send failed
Wed Apr 21 19:13:12 2021 daemon.notice hostapd: handle_probe_req: send failed
Wed Apr 21 19:13:12 2021 daemon.notice hostapd: handle_probe_req: send failed
Wed Apr 21 19:13:13 2021 daemon.notice hostapd: handle_probe_req: send failed
Wed Apr 21 19:13:13 2021 daemon.info hostapd: wlan1: STA c4:9d:ed:ae:75:4f IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Wed Apr 21 19:13:13 2021 daemon.notice hostapd: handle_probe_req: send failed
Wed Apr 21 19:13:13 2021 daemon.notice hostapd: handle_probe_req: send failed
Wed Apr 21 19:13:14 2021 kern.info kernel: [ 5713.621456] br-lan: port 3(wlan1) entered blocking state
Wed Apr 21 19:13:14 2021 kern.info kernel: [ 5713.627004] br-lan: port 3(wlan1) entered forwarding state
Wed Apr 21 19:13:14 2021 daemon.notice netifd: Network device 'wlan1' link is up
Wed Apr 21 19:13:14 2021 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED fa:88:58:33:99:cd
Wed Apr 21 19:13:14 2021 daemon.info hostapd: wlan1: STA fa:88:58:33:99:cd IEEE 802.11: disassociated
Wed Apr 21 19:13:15 2021 daemon.info hostapd: wlan1: STA fa:88:58:33:99:cd IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Wed Apr 21 19:13:16 2021 daemon.info hostapd: wlan1: STA c4:9d:ed:ae:75:4f IEEE 802.11: authenticated
Wed Apr 21 19:13:16 2021 daemon.info hostapd: wlan1: STA c4:9d:ed:ae:75:4f IEEE 802.11: associated (aid 1)
Wed Apr 21 19:13:16 2021 daemon.notice hostapd: wlan1: AP-STA-CONNECTED c4:9d:ed:ae:75:4f
Wed Apr 21 19:13:16 2021 daemon.info hostapd: wlan1: STA c4:9d:ed:ae:75:4f RADIUS: starting accounting session 1B18F3CE8713723C
Wed Apr 21 19:13:16 2021 daemon.info hostapd: wlan1: STA c4:9d:ed:ae:75:4f WPA: pairwise key handshake completed (RSN)
Wed Apr 21 19:13:16 2021 daemon.err stubby[2421]: Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports
Wed Apr 21 19:13:16 2021 daemon.err stubby[2421]: Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports
Wed Apr 21 19:13:16 2021 daemon.err stubby[2421]: Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports
Wed Apr 21 19:13:16 2021 daemon.err stubby[2421]: Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports
Wed Apr 21 19:13:16 2021 daemon.err stubby[2421]: Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports

config wifi-iface 'sta'
        option device 'radio0'
        option network 'wwan'
        option mode 'sta'
        option ifname 'wlan-sta'
        option ssid 'CenturyLink5245_5G'
        option bssid '54:83:3A:89:F0:7A'
        option channel '149'
        option encryption 'psk-mixed'
        option key '[redacted]'
        option disabled '0'

LuCI stats on the connection:

Network: Client “CenturyLink5245_5G” (wlan-sta)
MAC-Address: 54:83:3A:89:F0:7A
Host: ?
Signal / Noise: -57/-104 dBm
RX Rate / TX Rate: 390.0 Mbit/s, 80 MHz, VHT-MCS 8, VHT-NSS 1, Short GI 6.0 Mbit/s, 20 MHz

[mrbot]

This annoying bug seems persistent as it already exists in the 3.105.
You can read about it and the solution in this previous post from wellnw

TL;DR:

• kill gl_health process & delete the gl_health package
• install travelmate (readme) and luci-app-travelmate
• enter the luci page Services/Travelmate
• configure

If I remember correctly, I tough the team added a fix? @Johnex

[SlothCroissant]

@mrbot I saw that thread previously and assumed it didn’t apply as the fix was allegedly added to firmware, and I’m on the latest.

Regardless, gave it a go - I don’t have a package called gl-health or any variation as such. I have one called gl-repeater, which in its description says “GL Health” - is this the same?

I’ve setup travelmate regardless, and will see if the drops continue.

[SlothCroissant]

Issues persist, unfortunately.

Can someone confirm what package I should be removing, since gl_health isn’t on my device?

[viajeros]

I think there is the same problem with the AR300M model.

GL-AR300M: Long video conference breaks Wi-Fi

The symptoms seem to be similar to this issue #13681 (ar71xx: wr741nd wifi crash after some time) – OpenWrt

GL-AR300M: Long video conference breaks Wi-Fi

@luochongjun, I’m back with the results. Switching to the latest snapshot version of openwrt based on ath9 fixed the issue with Wi-Fi. Wi-Fi is fast and stable now! This could be the end of story however WAN link turned out to be unstable this time. ETH1 interface keeps up and down frequently. I dug a bit into the issue with WAN link and found that reverting a couple of commits from the master branch and rebuilding the image solves the issue with WAN too. Result: Now my GL-AR300M works withou…

GL-AR300M: Long video conference breaks Wi-Fi

@alzhao, upgrading to 19.07.3 didn’t solve Wi-Fi issue for me. Only upgrading to the latest master did (which will become 20.x version at some point). Firmware Version: OpenWrt SNAPSHOT r13835+2-8242c6de29 / LuCI Master git-20.192.49615-3dd289b

[alzhao]

@SlothCroissant

Can someone confirm what package I should be removing, since gl_health isn’t on my device?

gl_health is a process, not a package.

You can just do

/etc/init.d/gl_health stop
/etc/init.d/gl_health disable