AR750s Keeps disconnecting

jason240 · 2021-08-23T13:27:28.777Z

bump on sammo 's question - @satirebird - are you sure the problem is gone?

@alzhao the problem is not gone. I’m on 3.203 - i’ve used a few different power supplies and the problem still exists. It’s very trippable using speedtest.net, and it likes the upload portion. I’m testing often 90-110mbit on it over 5ghz at 20-30 dbm settings. I have my ar750s joined over to another ar750s also on 3.203 that has the direct connection to the wan. The ar750s is connected up using 5ghz for the “internet” link.

I connect to this system remotely and it has left me SOL many atime. I have went through a handful of good quality power supplies - power supply is NOT the issue. It’s a firmware or device driver bug. I’ve looked at kernel logs as it has the issue, I just get this - note as of today I’ve switched over to travelmate - it restores the link after disassociation more reliably vs gl-health and I can have it fail over to 2ghz temporarily - some connections don’t break (ssh to router) - others (teamviewer) still do. So problem has not been solved in existing firmware nor is travelmate a sure workaround, it just bumps the robustness up a bit.

[ 2152.113039] wlan1: send auth to 94:83:c4:0c:d5:35 (try 1/3)
[ 2152.123947] wlan1: authenticated
[ 2152.152118] wlan1: associate with 94:83:c4:0c:d5:35 (try 1/3)
[ 2152.162507] wlan1: RX AssocResp from 94:83:c4:0c:d5:35 (capab=0x31 status=0 aid=9)
[ 2152.170851] wlan1: associated
[ 2232.102892] wlan1: deauthenticating from 94:83:c4:0c:d5:35 by local choice (Reason: 3=DEAUTH_LEAVING)
[ 2232.541029] wlan-sta: deauthenticating from 94:83:c4:0c:d5:36 by local choice (Reason: 3=DEAUTH_LEAVING)
[ 2233.161831] br-lan: port 2(eth0.2) entered disabled state
[ 2233.297450] br-lan: port 2(eth0.2) entered blocking state
[ 2233.303081] br-lan: port 2(eth0.2) entered forwarding state
[ 2238.563798] ath10k_pci 0000:00:00.0: pdev param 0 not supported by firmware
[ 2241.324606] wlan1: authenticate with 94:83:c4:0c:d5:35
[ 2241.342901] wlan1: send auth to 94:83:c4:0c:d5:35 (try 1/3)
[ 2241.362094] wlan1: authenticated
[ 2241.392024] wlan1: associate with 94:83:c4:0c:d5:35 (try 1/3)
[ 2241.402302] wlan1: RX AssocResp from 94:83:c4:0c:d5:35 (capab=0x31 status=0 aid=9)
[ 2241.410399] wlan1: associated
[ 2242.640628] wlan-sta: authenticate with 94:83:c4:0c:d5:36
[ 2242.651615] wlan-sta: send auth to 94:83:c4:0c:d5:36 (try 1/3)
[ 2242.659580] wlan-sta: authenticated
[ 2242.672085] wlan-sta: associate with 94:83:c4:0c:d5:36 (try 1/3)
[ 2242.680064] wlan-sta: RX AssocResp from 94:83:c4:0c:d5:36 (capab=0x11 status=0 aid=2)
[ 2242.689833] wlan-sta: associated
[ 2250.674067] wlan1: deauthenticating from 94:83:c4:0c:d5:35 by local choice (Reason: 3=DEAUTH_LEAVING)
[ 2260.518637] wlan-sta: deauthenticating from 94:83:c4:0c:d5:36 by local choice (Reason: 3=DEAUTH_LEAVING)
[ 2263.885676] ath10k_pci 0000:00:00.0: pdev param 0 not supported by firmware
[ 2267.272840] wlan-sta: authenticate with 94:83:c4:0c:d5:36
[ 2267.288374] wlan-sta: send auth to 94:83:c4:0c:d5:36 (try 1/3)
[ 2267.297202] wlan-sta: authenticated
[ 2267.332080] wlan-sta: associate with 94:83:c4:0c:d5:36 (try 1/3)
[ 2267.361988] wlan-sta: RX AssocResp from 94:83:c4:0c:d5:36 (capab=0x11 status=0 aid=2)
[ 2267.392633] wlan-sta: associated
[ 3212.249548] wlan-sta: deauthenticating from 94:83:c4:0c:d5:36 by local choice (Reason: 3=DEAUTH_LEAVING)
[ 3241.595580] ath10k_pci 0000:00:00.0: pdev param 0 not supported by firmware
[ 3244.705962] wlan-sta: authenticate with 94:83:c4:0c:d5:36
[ 3244.721181] wlan-sta: send auth to 94:83:c4:0c:d5:36 (try 1/3)
[ 3244.728988] wlan-sta: authenticated
[ 3244.750590] wlan-sta: associate with 94:83:c4:0c:d5:36 (try 1/3)
[ 3244.760716] wlan-sta: RX AssocResp from 94:83:c4:0c:d5:36 (capab=0x11 status=0 aid=2)
[ 3244.781282] wlan-sta: associated

alzhao · 2021-08-24T04:42:01.411Z

The logs shows the problem of ath10k, not ath9k @satirebird mentioned.

I just tried to use one AR750S to repeat another AR750s on 5G and I don’t have any problem. Both using 3.203 firmware.

Did you every use any mac clone etc. on the router?

jason240 · 2021-08-24T05:19:41.666Z

No - I didn’t use anything interesting - no mac cloning - both radios have their original macs - I don’t have vpn or wireguard on the repeater having the problem. The connection can survive for days if you don’t really use it, and can last a while under light usage (remote desktop being something that can crash it every 15 minutes) - do something like speedtest.net and push 12MiB/s through it, at least 10 MiB/s up, do this like 5 different times over the coarse of an hour - it works fine for a little while depending on if you’re giving the client router a load. Whenever it crashed for me on speed tests it always happened in the upload portion of the test.

If you have anything you want to test or to pull from it, let me know.

Also I don’t have it set in “repeater” mode - from the client router’s pov the wan is the router it’s connecting to. I did this because I wanted separate networks with a route defined. Other pcs are hooked up to the repeater, but they’re wired.

satirebird · 2021-08-24T11:23:25.887Z

bump on sammo 's question - @satirebird - are you sure the problem is gone?

Yes I am sure. I made several tests using iperf in both directions. With the official firmware the de-authentication happens within the first minute of testing. I had a lot of trouble with that. With the new OpenWRT 21.02.0-rc4 the iperf tests runs without issues (I have tested it for 30 minutes at full load). My AR750S is configured as repeater. The uplink uses a 2.4G link to the router. The client is connected with a 5G link to the AR750S.

Note that I am not using the official glinet release. I am using the plain OpenWRT.

root@OpenWrt:~# uname -a
Linux OpenWrt 5.4.137 #0 Sat Jul 31 17:21:01 2021 mips GNU/Linux

Bildschirmfoto von 2021-08-24 13-15-34904×267 23.6 KB

jason240 · 2021-08-24T16:04:36.380Z

@alzhao can you prepare a test image against 21.02.0-rc4?

alzhao · 2021-08-25T06:32:37.627Z

We are working on firmware 4.x which has many changes. Hopefully we will use 21.02 as the basic openwrt distro.

jason240 · 2021-08-25T06:52:29.996Z

@alzhao do you have a timeline, even for just a test with “yes it boots” beta quality or same version as now with the new kernel patches? I’m trying to avoid going onto openwrt directly and avoiding losing some of the settings I have if you guys can just slap out a test so we get the solution verified for your images. I can update your software builds remotely where as I need to be physically present for the openwrt conversion too.

alzhao · 2021-08-25T11:12:12.355Z

jason240:

I’m trying to avoid going onto openwrt directly and avoiding losing some of the settings I have if you guys can just slap out a test so we get the solution verified for your images. I can update your software builds remotely where as I need to be physically present for the openwrt conversion too.

We should have firmware 4.x beta in end of this year.

diver68 · 2021-08-26T04:34:45.448Z

Had the same problems with GL.Inet FW. Flashed the AR750S to OpenWrt 21.02 RC4, since then no more drops. Repeat on 2.4 and distribute on 5GHz

jason240 · 2021-09-02T03:54:25.676Z

@alzhao confirming it also works reliably for me to use the rc4 from openwrt the others are using. I use 5ghz for my uplink to the other ar750s.

How about you guys just backport the kernel and release an update rather than kicking things out so long.

I have a slight preference for your packaging of openwrt rather than openwrt itself, which kind of gives me both… with this probably don’t have to do travelmate anything either over gl health.

sammo · 2021-09-02T06:43:23.082Z

Repeat on 2.4 and distribute on 5GHz. <= That might work, but set you 5g to non dfs
I use 5ghz for my uplink to the other ar750s. <=. Just be careful it’s a non dfs uplink

On 5g, there is only 1 band which is non dfs or 2 if in usa

NetBeez – 5 Dec 18

Using DFS Channels in WiFi

DFS channels add more usable frequencies for the deployment of WLANs. Before enabling this WiFi function, learn some important implications with radar signals.

alzhao · 2021-09-02T09:12:27.747Z

From here Archer C7 2.4 GHz wireless dies in 24~48 hours - #225 by sammo - Network and Wireless Configuration - OpenWrt Forum

Is the fix increasing memory_limit ?

Seems I cannot get a definite answer on this one.

gokturk · 2021-09-02T20:05:32.353Z

alzhao:

The logs shows the problem of ath10k, not ath9k @satirebird mentioned.

I just tried to use one AR750S to repeat another AR750s on 5G and I don’t have any problem. Both using 3.203 firmware.

Did you every use any mac clone etc. on the router?

I have thrown away the router for since my last post. turned back to old tplink. Today came back because ı needed it for something. And see that you are still insisting that you cannot replicate the problem. Futher you are still fiddling with 5G…turn off 5G man… the problem is 2.4 to 2.4…
best regards…

Also: auto update fails with bad md5 verification… fail…

how could this take soo long?

sammo · 2021-09-02T20:24:58.235Z

@gokturk,. I don’t have ar750s but ar750 which has a slightly different 2.4ghz chipset. To compare notes, with repeater on 2.4ghz do you see in logread beacon loss and then a disconnect?

gokturk · 2021-09-03T12:02:48.836Z

update:

updated to latest firmware. no problems so far in about a day…

(solved the update issue by following all consequtive uptades one by one)

booz · 2021-09-25T12:44:55.804Z

Has anyone had any joy when running an AP on 2.4GHz radio using openwrt 21.02? My recent experience is if I do client on 2.4GHz and AP on 5GHz everything is stable and fine. As soon as I introduce AP onto the 2.4GHz radio the router keeps rebooting itself and only luck lets me get back in and disable that 2.4G AP in order for it to work reliably again. @goturk did you have any luck getting it to work?

booz · 2021-09-27T07:48:57.003Z

I would like to add that although it is relatively stable it still randomly reboots itself after several hours, and most commonly as soon as I log into the luci interface. Free space looks fine. I am running wireguard but nothing else

alzhao · 2021-09-27T11:55:20.131Z

Maybe just try:

A different power adapter

Different WiFi encryption and tax output power

booz · 2021-09-27T12:26:55.897Z

I’ve dropped the output power on both radios to 25mW - seems to be going well so far. Have set WPA2/WPA3 mixed as the encryption

alzhao · 2021-09-27T12:32:47.085Z

WPA3 could be a problem but I am not sure.