You are not logged in.
When there's a power problem you can get all kinds of erratic problems
OK. I'll try as soon as the desktop PC is available. It has an expansion card with 2 USB3 slots.
Offline
the band-switching issue
What do you mean here?
Wrt. the power saving theory: if you first run a scan and then immediately connect to the AP afterwards, does that work?
user@laptop:~$ nmcli device wifi list --rescan yes ifname wlp0s29f7u7 bssid D8:07:B6:D6:B3:39; nmcli device wifi connect D8:07:B6:D6:B3:39 ifname wlp0s29f7u7
IN-USE BSSID SSID MODE CHAN RATE SIGNAL BARS SECURITY
D8:07:B6:D6:B3:39 casillas5 Infra 44 270 Mbit/s 90 ▂▄▆█ WPA2
Error: Connection activation failed: (53) The Wi-Fi network could not be found.
I tried a few possible workarounds already, but no success so far. But if you can think of anything, don't hesitate.
for the scan needs to wake the chip and make its use its radio, idk how it could not be ready at this point
I agree, but then, two consecutive connection attempts should do the trick too, right? I don't see why but it doesn't either. Believe me, when I have a workaround I chuck it in a script, hook it up to the boot process and have a beer at last
Offline
What do you mean here?
Not being able to go from 2.4GHz to 5GHz and vv w/o having to re-plug the dongle.
two consecutive connection attempts should do the trick too, right?
Right, and that rather defeats the wake-up-issue idea
nmcli device wifi list --rescan yes ifname wlp0s29f7u7 bssid D8:07:B6:D6:B3:39; sleep 12; nmcli device wifi connect D8:07:B6:D6:B3:39 ifname wlp0s29f7u7
Offline
user@laptop:~$ nmcli device wifi list --rescan yes ifname wlp0s29f7u7 bssid D8:07:B6:D6:B3:39; sleep 12; nmcli device wifi connect D8:07:B6:D6:B3:39 ifname wlp0s29f7u7
IN-USE BSSID SSID MODE CHAN RATE SIGNAL BARS SECURITY
D8:07:B6:D6:B3:39 casillas5 Infra 44 270 Mbit/s 84 ▂▄▆█ WPA2
Error: Connection activation failed: (53) The Wi-Fi network could not be found.
Nice try
Not being able to go from 2.4GHz to 5GHz and vv w/o having to re-plug the dongle.
You're right. I had completely forgotten because I created NetworkManager profiles for two different USB slots. I boot the laptop with the dongle in one USB slot. That slot has a NetworkManager profile that connects to the 2.4 GHz network without a problem.
If I need to transfer a large file, I swap the dongle (resetting it on the fly) to a different USB slot. That slot has a 5 GHz NetworkManager profile. Then it's a matter of sit back and wait for the dongle to connect and, when it is up and running, hope that the speed of the file transfer compensates for the time it took to connect.
Offline
What if you remove the WPA2 and leave the AP unencrypted (for a test - obviously don't hang out an open WiFi for everyone to abuse…)?
Offline
When there's a power problem you can get all kinds of erratic problems
So I tried with the dongle plugged into a desktop PC USB3 slot. With interesting results!
user@BBB:~$ sleep 30; time nmcli device wifi connect D8:07:B6:D6:B3:39 ifname wlp2s0u1
Device 'wlp2s0u1' successfully activated with '92b78895-2495-4a68-ac4e-beb2064d0aab'.
real 0m14,998s
user 0m0,052s
sys 0m0,000s
user@BBB:~$ time nmcli device wifi connect D8:07:B6:D6:B3:39 ifname wlp2s0u1
Device 'wlp2s0u1' successfully activated with '92b78895-2495-4a68-ac4e-beb2064d0aab'.
real 0m15,065s
user 0m0,031s
sys 0m0,022s
user@BBB:~$ time nmcli device wifi connect D8:07:B6:D6:B3:39 ifname wlp2s0u1
Device 'wlp2s0u1' successfully activated with '92b78895-2495-4a68-ac4e-beb2064d0aab'.
real 0m17,274s
user 0m0,053s
sys 0m0,000s
But, don't get excited. Because once connected:
user@BBB:~$ sleep 30; ping 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
64 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=6772 ms
From 192.168.0.10 icmp_seq=9 Destination Host Unreachable
From 192.168.0.10 icmp_seq=10 Destination Host Unreachable
From 192.168.0.10 icmp_seq=11 Destination Host Unreachable
64 bytes from 192.168.0.1: icmp_seq=2 ttl=64 time=17114 ms
64 bytes from 192.168.0.1: icmp_seq=3 ttl=64 time=16074 ms
64 bytes from 192.168.0.1: icmp_seq=4 ttl=64 time=15034 ms
64 bytes from 192.168.0.1: icmp_seq=5 ttl=64 time=13994 ms
64 bytes from 192.168.0.1: icmp_seq=17 ttl=64 time=9377 ms
64 bytes from 192.168.0.1: icmp_seq=18 ttl=64 time=8337 ms
64 bytes from 192.168.0.1: icmp_seq=19 ttl=64 time=7440 ms
64 bytes from 192.168.0.1: icmp_seq=20 ttl=64 time=6361 ms
64 bytes from 192.168.0.1: icmp_seq=21 ttl=64 time=5321 ms
64 bytes from 192.168.0.1: icmp_seq=22 ttl=64 time=4281 ms
64 bytes from 192.168.0.1: icmp_seq=23 ttl=64 time=3242 ms
64 bytes from 192.168.0.1: icmp_seq=24 ttl=64 time=2202 ms
64 bytes from 192.168.0.1: icmp_seq=25 ttl=64 time=10880 ms
64 bytes from 192.168.0.1: icmp_seq=26 ttl=64 time=9840 ms
64 bytes from 192.168.0.1: icmp_seq=27 ttl=64 time=8840 ms
64 bytes from 192.168.0.1: icmp_seq=28 ttl=64 time=7761 ms
64 bytes from 192.168.0.1: icmp_seq=29 ttl=64 time=6721 ms
64 bytes from 192.168.0.1: icmp_seq=30 ttl=64 time=5682 ms
64 bytes from 192.168.0.1: icmp_seq=31 ttl=64 time=4642 ms
64 bytes from 192.168.0.1: icmp_seq=32 ttl=64 time=3602 ms
64 bytes from 192.168.0.1: icmp_seq=36 ttl=64 time=799 ms
64 bytes from 192.168.0.1: icmp_seq=37 ttl=64 time=196 ms
64 bytes from 192.168.0.1: icmp_seq=38 ttl=64 time=285 ms
64 bytes from 192.168.0.1: icmp_seq=39 ttl=64 time=199 ms
64 bytes from 192.168.0.1: icmp_seq=40 ttl=64 time=46.9 ms
64 bytes from 192.168.0.1: icmp_seq=41 ttl=64 time=91.3 ms
64 bytes from 192.168.0.1: icmp_seq=42 ttl=64 time=128 ms
IMHO there are two issues. There is a power issue. At connecting. And once connected, there is something in the kernel module that makes the device decide to have a nap. Only in 5 GHz mode. 2.4 GHz mode works fine. Agree?
Offline
What if you remove the WPA2 and leave the AP unencrypted
user@laptop:~$ nmcli device wifi list --rescan yes ifname wlp0s29f7u7 bssid D8:07:B6:D6:B3:39; nmcli device wifi connect D8:07:B6:D6:B3:39 ifname wlp0s29f7u7
IN-USE BSSID SSID MODE CHAN RATE SIGNAL BARS SECURITY
D8:07:B6:D6:B3:39 casillas5 Infra 44 270 Mbit/s 82 ▂▄▆█ --
Error: Connection activation failed: (53) The Wi-Fi network could not be found.
Offline
The pings are way too high. The network connection is fighting. This could also be external interferences/walls/distance problems. How far are you away from the AP? Any walls in-between?
The AP (especially on OpenWrt) could make trouble as well. What firmware version is on your TP-Link EAP225 (v21.02.3 is latest stable)?
Last edited by Maniaxx (2022-09-03 17:07:05)
sys2064
Offline
The pings are way too high. The network connection is fighting. This could also be external interferences/walls/distance problems. How far are you away from the AP? Any walls in-between?
No walls. Just an open door. Maybe I interrupted ping too soon because I think that the response times end up around 1..2 ms. Note that they start at 17114 ms and 11 packets get lost completely.
The AP (especially on OpenWrt) could make trouble as well. What firmware version is on your TP-Link EAP225 (v21.02.3 is latest stable)?
OpenWrt 21.02.1 r16325-88151b8303. Have there been significant changes since?
Offline
significant changes since?
Who knows. You're running the first version of a major release. Updating is easy so why not taking the bug fixes and updates. You might have a chipset with still WIP drivers indeed. You could also test v22.03.0-rc6 release. New kernel, new chances.
Edit:
I guess you have a Qualcomm Atheros QCA9886 for 5GHz. There are several complaints about the CT firmware and people switch to the original firmware. There are many threads about this issue. Not sure where to link to. Maybe this is a good start: https://github.com/greearb/ath10k-ct/is … -640609415
In short, switch from 'ath10k-firmware-qca988x-ct' to 'ath10k-firmware-qca988x'. But that's just how i understand it (without having the device). Use 'opkg list-installed | grep ath10k' wisely to make sure what you need (and that the above informations are correct).
If by any chance you can get in range of another 5GHz AP try the stick there first. Its still completely unknown who's the culprit here.
Last edited by Maniaxx (2022-09-03 20:27:32)
sys2064
Offline
Interesting. You do openwrt as well!
root@EAP225:~# opkg list-installed | grep ath10k
ath10k-board-qca9888 - 20201118-3
ath10k-firmware-qca9888-ct - 2020-11-08-1
kmod-ath10k-ct - 5.4.154+2021-09-22-e6a7d5b5-1
root@EAP225:~# opkg list-upgradable | grep ath10k
ath10k-board-qca9888 - 20201118-3 - 20211216-1
So I will upgrade this package. But replace the other packages with the non -ct alternatives... The github users aren't clear about the results.
Updating is easy
From 21.02.1 to 21.02.3? Download sources, menuconfig, compile toolchain, cross-compile sources, package packages, and generate an image. Takes many hours here.
If by any chance you can get in range of another 5GHz AP try the stick there first
Done that in post #45. With interesting results...
Offline
root@EAP225:~# opkg upgrade ath10k-board-qca9888
Upgrading ath10k-board-qca9888 on root from 20201118-3 to 20211216-1...
Downloading https://downloads.openwrt.org/releases/21.02.1/packages/mips_24kc/base/ath10k-board-qca9888_20211216-1_mips_24kc.ipk
Configuring ath10k-board-qca9888.
root@EAP225:~# reboot
user@laptop:~$ nmcli device wifi list --rescan yes ifname wlp0s29f7u7 bssid D8:07:B6:D6:B3:39
IN-USE BSSID SSID MODE CHAN RATE SIGNAL BARS SECURITY
D8:07:B6:D6:B3:39 casillas5 Infra 48 270 Mbit/s 85 ▂▄▆█ WPA2
user@laptop:~$ nmcli device wifi connect D8:07:B6:D6:B3:39 ifname wlp0s29f7u7
Device 'wlp0s29f7u7' successfully activated with 'ba724fbb-e23b-4383-99c6-3aa4822271eb'.
Never seen that! Maybe even the solution. More testing needed, but promising
Offline
Cross check: did you ever before reboot the router since noticing these issues?
Offline
What's the reason you compile manually?
sys2064
Offline
After booting the laptop today the dongle connected automatically in the second attempt. So within a minute or so. That's a giant step forward. Especially considering that the dongle seems to need more power (during connection) than these USB2 ports supply. That may cause the first attempt to fail.
Once connected pings are in the range 1..2 ms and speed is consistently 5x..6x the laptop built-in wifi. Not bad!
Cross check: did you ever before reboot the router since noticing these issues?
I received the dongle 1 Aug. That's when the trouble started. The AP reboots day 9 of every month from the crontab. So last reboot was 9 Aug.
I wish I could tell you what was changed in ath10k-board-qca9888 but I don't know how to find out.
What's the reason you compile manually?
You mean why not grab the ready firmware and flash it? The short answer is because I want to tweak busybox with e.g. FEATURE_EDITING_SAVEHISTORY. The long answer is that after compiling a release for three different routers, it's relatively easy to compile a new firmware for this AP as well.
Offline
You could just compile busybox package and feed it to the stock image. But that's a different story.
So, there's a kmod driver and a firmware to swap (no matter what firmware). I guess you will try that?
sys2064
Offline
So, there's a kmod driver and a firmware to swap (no matter what firmware). I guess you will try that?
Yes. On the one hand because I think I owe it to you both, on the other hand because... well, I may have been overenthusiastic. It looks as if connecting is taking a little longer every time, maybe because the new ath10k-board-qca9888 is not the ultimate solution it seemed to be or because the AP reboot had more impact, as suggested by seth.
Anyway, it is probably not wise to try and swap the packages in the AP from this laptop as the wireless connection is most probably going to crash in the process. Better tomorrow from a PC with a wired LAN connection.
Offline
Today I flashed the AP with the latest OpenWrt firmware (OpenWrt 21.02.3 r16554-1d4dea6d4f). And I swapped the CT kmod driver and firmware with the alternatives.
So now testing can begin.
Unfortunately the AP still seems to abort a connection attempt after 25 secs, 1st time connecting wasn't particularly quick (a few minutes and several attempts), iperf3 speed is not as impressive as it was in post #65 and I saw something I thought I'd got rid of:
user@laptop:~$ ping 192.168.0.20
PING 192.168.0.20 (192.168.0.20) 56(84) bytes of data.
64 bytes from 192.168.0.20: icmp_seq=1 ttl=64 time=134 ms
64 bytes from 192.168.0.20: icmp_seq=2 ttl=64 time=66.7 ms
64 bytes from 192.168.0.20: icmp_seq=3 ttl=64 time=2968 ms
64 bytes from 192.168.0.20: icmp_seq=4 ttl=64 time=1943 ms
64 bytes from 192.168.0.20: icmp_seq=5 ttl=64 time=905 ms
From 192.168.0.10 icmp_seq=9 Destination Host Unreachable
From 192.168.0.10 icmp_seq=10 Destination Host Unreachable
From 192.168.0.10 icmp_seq=11 Destination Host Unreachable
From 192.168.0.10 icmp_seq=12 Destination Host Unreachable
From 192.168.0.10 icmp_seq=13 Destination Host Unreachable
From 192.168.0.10 icmp_seq=14 Destination Host Unreachable
From 192.168.0.10 icmp_seq=15 Destination Host Unreachable
From 192.168.0.10 icmp_seq=16 Destination Host Unreachable
From 192.168.0.10 icmp_seq=17 Destination Host Unreachable
64 bytes from 192.168.0.20: icmp_seq=6 ttl=64 time=12922 ms
64 bytes from 192.168.0.20: icmp_seq=7 ttl=64 time=11910 ms
64 bytes from 192.168.0.20: icmp_seq=8 ttl=64 time=10891 ms
64 bytes from 192.168.0.20: icmp_seq=19 ttl=64 time=639 ms
64 bytes from 192.168.0.20: icmp_seq=20 ttl=64 time=7340 ms
64 bytes from 192.168.0.20: icmp_seq=21 ttl=64 time=6390 ms
64 bytes from 192.168.0.20: icmp_seq=22 ttl=64 time=5358 ms
64 bytes from 192.168.0.20: icmp_seq=23 ttl=64 time=4320 ms
64 bytes from 192.168.0.20: icmp_seq=24 ttl=64 time=3282 ms
64 bytes from 192.168.0.20: icmp_seq=25 ttl=64 time=2265 ms
64 bytes from 192.168.0.20: icmp_seq=26 ttl=64 time=1252 ms
64 bytes from 192.168.0.20: icmp_seq=27 ttl=64 time=218 ms
64 bytes from 192.168.0.20: icmp_seq=28 ttl=64 time=8.48 ms
64 bytes from 192.168.0.20: icmp_seq=29 ttl=64 time=3.34 ms
64 bytes from 192.168.0.20: icmp_seq=30 ttl=64 time=1.17 ms
64 bytes from 192.168.0.20: icmp_seq=31 ttl=64 time=1.06 ms
64 bytes from 192.168.0.20: icmp_seq=32 ttl=64 time=1.02 ms
64 bytes from 192.168.0.20: icmp_seq=33 ttl=64 time=0.930 ms
64 bytes from 192.168.0.20: icmp_seq=34 ttl=64 time=1.15 ms
64 bytes from 192.168.0.20: icmp_seq=35 ttl=64 time=0.946 ms
64 bytes from 192.168.0.20: icmp_seq=36 ttl=64 time=0.826 ms
64 bytes from 192.168.0.20: icmp_seq=37 ttl=64 time=1.09 ms
64 bytes from 192.168.0.20: icmp_seq=38 ttl=64 time=1.16 ms
64 bytes from 192.168.0.20: icmp_seq=39 ttl=64 time=1.81 ms
64 bytes from 192.168.0.20: icmp_seq=40 ttl=64 time=1.05 ms
64 bytes from 192.168.0.20: icmp_seq=41 ttl=64 time=1.03 ms
64 bytes from 192.168.0.20: icmp_seq=42 ttl=64 time=0.900 ms
64 bytes from 192.168.0.20: icmp_seq=43 ttl=64 time=0.924 ms
64 bytes from 192.168.0.20: icmp_seq=44 ttl=64 time=0.770 ms
64 bytes from 192.168.0.20: icmp_seq=45 ttl=64 time=1.40 ms
64 bytes from 192.168.0.20: icmp_seq=46 ttl=64 time=0.823 ms
64 bytes from 192.168.0.20: icmp_seq=47 ttl=64 time=1.22 ms
64 bytes from 192.168.0.20: icmp_seq=48 ttl=64 time=0.989 ms
64 bytes from 192.168.0.20: icmp_seq=49 ttl=64 time=1.10 ms
64 bytes from 192.168.0.20: icmp_seq=50 ttl=64 time=0.768 ms
BTW, 192.168.0.20 is the IP address of the AP. I ping its IP address because otherwise I get an error that EAP225 cannot be resolved. Due to the loss of network connectivity.
To be continued.
Offline
Do you have any ANI (Adaptive Noise Immunity) entries in sysfs? If so, try to disable it.
/sys/kernel/debug/ieee80211/phy*/ath10k/ani_enable
Can you test some other WiFi devices (smartphones, etc) via 5GHz on that AP?
Last edited by Maniaxx (2022-09-05 21:55:52)
sys2064
Offline
Can you test some other WiFi devices (smartphones, etc) via 5GHz on that AP?
There are two phones and one Netgear R6220 router connected to the AP via 5 GHz. Without any problem. The Netgear router has been converted into a kind of mediabox. It records streams several times a day without a flaw (knock wood).
root@EAP225:~# cat /sys/kernel/debug/ieee80211/phy*/ath10k/ani_enable
1
root@EAP225:~# echo 0 > /sys/kernel/debug/ieee80211/phy0/ath10k/ani_enable
root@EAP225:~# cat /sys/kernel/debug/ieee80211/phy*/ath10k/ani_enable
0
Offline
Can these AP LuCI wireless interface settings have any effect? I put the current value between parentheses:
Short Preamble (enabled)
DTIM Interval (2)
Disable Inactivity Polling (disabled)
Station inactivity limit (300)
Maximum allowed Listen Interval (65535)
Disassociate On Low Acknowledgement (enabled)
Offline
Disable Inactivity Polling (disabled)
Disassociate On Low Acknowledgement (enabled)
You could trigger these for testing.
But if other devices run flawless it doesn't look all too bad for the AP.
sys2064
Offline
root@EAP225:~# echo 0 > /sys/kernel/debug/ieee80211/phy0/ath10k/ani_enable
Doesn't make things better nor worse.
Offline
So I tried the dongle with a Windows PC. Without installing the driver provided on CD, so with the default Windows driver, the dongle connected to both 2.4 and 5 GHz networks without any problem and almost immediately. Without having to unplug it before switching networks.
The speed was more difficult to find out as I couldn't find iperf3 in Windows . Therefore I used the ISP speed test. It showed 14 Mbps download and 17 Mbps upload speed connected to the 2.4 GHz network and 20 Mbps download and 48 Mbps upload speed connected to the 5 GHz network. Not impressive probably because of the larger distance to the AP but stable and usable.
Worth mentioning that the USB slot was an ordinary 2.0 USB port and also that the dongle LED switched on. It turns out it is a blue LED. I hadn't discovered that with linux.
BTW, before I had also tried with a Raspberry Pi 3 model B+. Again 2.0 USB ports. This model has 4 of these. The firmware was missing and had to be installed manually. The results were worse than with arch on laptop and desktop. Connecting took ages when it did at all, speed terrible.
Offline
Worth mentioning that the USB slot was an ordinary 2.0 USB
Not all usb ports are make alike - particularily not when it comes to the allowed current. So this isn't a conclusive test.
Can you run eg. a linux live distro on that PC?
(Even if it doesn't have the mt76xu0u modules, the dongle's LED might flare up merely on access…)
Offline