I have tested the new openwrt 21.02.0-rc4 release. The problem seems to be fixed. I have no issues. The update image comes from here.
I used the “nor” file glinet_gl-ar750s-nor-squashfs-sysupgrade.bin and flashed it using the debricking interface I am not sure what’s the difference between nor-nand and nor image but the nor image seems to work.
I also installed the travelmate package described above and made some tests in the same environment. The 2.4G uplink stable!
Are you sure? My tests indicate there is still a problem. Try iperf over 2.4Ghz while upload a file. It will soon fail
After reading this I now understand why I had so much trouble this past week when I was traveling! The hotels where I could plug the AR750s in wired worked fine. The ones where I had to use it as a repeater was an exercise in frustration! At places where I had to use repeater mode, I usually ended up putting it away and not using it.
It would connect and work but then after a random period of time (so it seemed) it would hang. I was connected to it but I could not access the UI without a reboot and internet would be down.
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
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?
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.
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
We are working on firmware 4.x which has many changes. Hopefully we will use 21.02 as the basic openwrt distro.
@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.
We should have firmware 4.x beta in end of this year.
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
@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.
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
Is the fix increasing memory_limit ?
Seems I cannot get a definite answer on this one.
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?
@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?
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)
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?
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
