Drivers that scan available WiFi networks in chunks

[2m]

I am trying to find information on wifi drivers for Linux that scan for surrounding WiFi networks in chunks thus allowing to handle pending traffic.

I have found this mentioned vaguely in https://blogs.gnome.org/dcbw/2016/05/16/networkmanager-and-wifi-scans/ and was wondering maybe there is something that could indicate whether a driver supports such functionality or not.

The reason I am looking for this is that I need quite a stable connection for https://openmower.de/. It gets NTRIP data from a nearby GPS base station every second to get a GPS RTK lock. And I noticed that with ALFA Network AWUS036ACM network scan takes 20 seconds and during that time WiFi connection is not responsive.

I was able to shorten scan times to 8 seconds by changing the regulatory domain to BZ (iw reg set BZ) but that still causes some interruption for the GPS RTK signal.

[morrownr]

Hi @2m

I have many adapters that cover most of the chipsets that are available. I am willing to test and provide you with results if you provide me with a checklist (a list of commands) of exactly what to do and what you need to see.

There is also the option to craft a well done report and provide it to the Mediatek devs... or someone in the community could take a look and possibly submit a patch.

@morrownr

[2m]

Thank you for a quick response.

Currently I test my adapter by running sudo iw event | ts and checking the output to see how long scans take:

Jun 05 09:58:54 wlan0 (phy #0): scan started
Jun 05 09:59:01 wlan0 (phy #0): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 5745 5765 5785 5805 5825, "<ssid>"

Here it shows that scan takes 8 seconds. This is with BZ reg domain, without changing reg domain, it takes 20 seconds.

And parallel to that I am running ping from another machine to the one running the wifi adapter.

Jun 05 11:58:52 64 bytes from 100.64.10.87: icmp_seq=7495 ttl=64 time=25.891 ms
Jun 05 11:58:53 64 bytes from 100.64.10.87: icmp_seq=7496 ttl=64 time=23.702 ms
Jun 05 11:58:55 64 bytes from 100.64.10.87: icmp_seq=7497 ttl=64 time=313.352 ms
Jun 05 11:58:56 64 bytes from 100.64.10.87: icmp_seq=7498 ttl=64 time=207.916 ms
Jun 05 11:58:57 64 bytes from 100.64.10.87: icmp_seq=7499 ttl=64 time=162.252 ms
Jun 05 11:58:57 64 bytes from 100.64.10.87: icmp_seq=7500 ttl=64 time=115.556 ms
Jun 05 11:58:58 64 bytes from 100.64.10.87: icmp_seq=7501 ttl=64 time=77.317 ms
Jun 05 11:58:59 64 bytes from 100.64.10.87: icmp_seq=7502 ttl=64 time=43.195 ms
Jun 05 11:59:00 64 bytes from 100.64.10.87: icmp_seq=7503 ttl=64 time=20.804 ms
Jun 05 11:59:02 64 bytes from 100.64.10.87: icmp_seq=7505 ttl=64 time=99.035 ms
Jun 05 11:59:03 64 bytes from 100.64.10.87: icmp_seq=7506 ttl=64 time=20.805 ms
Jun 05 11:59:04 64 bytes from 100.64.10.87: icmp_seq=7507 ttl=64 time=21.460 ms

Here, with a shorter scan duration of 8 seconds, it does not look that bad. In fact it seems that traffic is still processed (albeit with a delay) during the scan. During longer scans it would start dropping packets.

Its a bit of a convoluted test, but currently I have not figured anything better.

[morrownr]

Here is the initial test. It is using a EDUP EP-AX1672 which is shown in the Plug and Play List. Why did I use it? It just happened to be what was connected to my test system. It uses the in-kernel mt7921u driver. My country code is US.

$ sudo iw event | ts
[sudo] password: xxx
Jun 05 11:37:35 wlxe84e06aa849b (phy #1): scan started
Jun 05 11:37:40 wlxe84e06aa849b (phy #1): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 5180 5200 5220 5240 5260 5280 5300 5320 5500 5520 5540 5560 5580 5600 5620 5640 5660 5680 5700 5720 5745 5765 5785 5805 5825 5845 5865 5885 5955 5975 5995 6015 6035 6055 6075 6095 6115 6135 6155 6175 6195 6215 6235 6255 6275 6295 6315 6335 6355 6375 6395 6415 6435 6455 6475 6495 6515 6535 6555 6575 6595 6615 6635 6655 6675 6695 6715 6735 6755 6775 6795 6815 6835 6855 6875 6895 6915 6935 6955 6975 6995 7015 7035 7055 7075 7095 7115, ""

I have an Alfa ACM. Would you like for me to post the result so as to compare?

What driver do you want me to test next?

[2m]

Oh wow, that is a big number of channels scanned and in a very short time. Did you notice any connectivity interruptions during the scan?

It would be great if you could try the adapter I have next - ALFA Network AWUS036ACM that uses mt76x2u driver - to compare the results.

[morrownr]

Did you notice any connectivity interruptions during the scan?

No. I ran ping while the test was running and I did not see any interruptions.

I will test the Alfa ACM next.

FYI: Test system runs Debian 12 with kernel 6.7. It is an x86_64 system.

... that is a big number of channels scanned and in a very short time.

It is a tri-band adapter similar to the Alfa AXM. Both use the same chip.

[2m]

FYI: Test system runs Debian 12 with kernel 6.7. It is an x86_64 system.

Ahh, very interesting what results you will see with AWUS036ACM. If they will be better, then my quite outdated OpenMower kernel might need an upgrade.

Debian GNU/Linux 11 (bullseye)
Linux openmower 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr  3 17:24:16 BST 2023 aarch64 GNU/Linux

[morrownr]

Test with Alfa ACM:

$ sudo iw event | ts
Jun 05 14:50:04 wlx00c0caadcb84 (phy #2): scan started
Jun 05 14:50:10 wlx00c0caadcb84 (phy #2): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 5180 5200 5220 5240 5260 5280 5300 5320 5500 5520 5540 5560 5580 5600 5620 5640 5660 5680 5700 5720 5745 5765 5785 5805 5825 5845 5865 5885, ""

I was running ping during the test:

64 bytes from 192.168.1.1: icmp_seq=126 ttl=64 time=0.630 ms
64 bytes from 192.168.1.1: icmp_seq=127 ttl=64 time=5.01 ms
64 bytes from 192.168.1.1: icmp_seq=128 ttl=64 time=2.92 ms
64 bytes from 192.168.1.1: icmp_seq=129 ttl=64 time=0.681 ms
64 bytes from 192.168.1.1: icmp_seq=130 ttl=64 time=6.68 ms
64 bytes from 192.168.1.1: icmp_seq=131 ttl=64 time=6.99 ms
64 bytes from 192.168.1.1: icmp_seq=132 ttl=64 time=6.70 ms
64 bytes from 192.168.1.1: icmp_seq=133 ttl=64 time=0.563 ms
64 bytes from 192.168.1.1: icmp_seq=134 ttl=64 time=7.31 ms
64 bytes from 192.168.1.1: icmp_seq=135 ttl=64 time=6.57 ms
64 bytes from 192.168.1.1: icmp_seq=136 ttl=64 time=1.26 ms
64 bytes from 192.168.1.1: icmp_seq=137 ttl=64 time=8.29 ms
64 bytes from 192.168.1.1: icmp_seq=138 ttl=64 time=1.02 ms
64 bytes from 192.168.1.1: icmp_seq=139 ttl=64 time=6.03 ms
...

Nothing even close to what I would call an interruption.

The test time did jump from 5 seconds to 6 in this test.

FYI: I am not running a flame throwing machine. It is an 11 year old Dell Vostro with an i7 quad core cpu and 12 gb of RAM. I think it is fast but some people might think it is an antique.

[2m]

FYI: I am not running a flame throwing machine. It is an 11 year old Dell Vostro with an i7 quad core cpu and 12 gb of RAM. I think it is fast but some people might think it is an antique.

Computers are veeeery fast. Its just that we tend to throw not that fast software at them. :)

Thank you very much for these tests. I think now it is quite clear that there have been improvements to this driver during the last 6 versions. I need to upgrade my kernel and pick it up from there.

[morrownr]

I need to upgrade my kernel and pick it up from there.

That likely will not hurt as it seems to me that around kernel 6.6 is a sweet spot for stability for now. It appears that as you get on up to around kernel 6.8 and later we are seeing some issues due to the very large amount of patches coming in to support WiFi 7. I'm not just talking about drivers but the entire Linux wifi stack. I posted an issue about this here yesterday. It will pass but for now sticking with a system like Debian 12 and kernel 6.6 (which Debian has available for installation) is really good.

I was trying to think if I am doing something different than you and something just popped into my head.

Here is the Alfa ACM interface as shown on my system currently:

$ iw dev
phy#2
	Interface wlx00c0caadcb84
		ifindex 5
		wdev 0x200000001
		addr 00:c0:ca:ad:cb:84
		type managed
		txpower 23.00 dBm
		multicast TXQ:
			qsz-byt	qsz-pkt	flows	drops	marks	overlmt	hashcol	tx-bytes	tx-packets
			0	0	0	0	0	0	0	0		0

Note that it is not connected to an AP and it was not connected while doing the tests. I usually have multiple adapters/cards on this system at any one time and it is even has an ethernet connection. I use different ways of connecting and different setups depending on what I am doing, I would not do scan tests on a wifi interface that is connected to an AP as you can see the results you are seeing or worse. Sorry about not thinking of this earlier but maybe it can help you find a solution to what you are trying to accomplish.

[2m]

Note that it is not connected to an AP and it was not connected while doing the tests.

Ahh, that makes sense and is most probably the reason of faster scan times and no interruptions to pings.

On my setup the OpenMower is moving in the yard and is constantly scanning (every 5 minutes when the signal is not too bad) for surrounding BSSIDs. I am using Network Manager with wpa_supplicant backend for connection management.

Would you mind making a test when the card is connected to the network?

[morrownr]

Test with Alfa ACM with the ACM connect to an AP...

$ sudo iw event | ts
[sudo] password: xxx
Jun 05 16:31:03 wlp3s0 (phy #0): scan started
Jun 05 16:31:06 wlp3s0 (phy #0): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 5180 5200 5220 5240 5260 5280 5300 5320 5500 5520 5540 5560 5580 5600 5620 5640 5660 5680 5700 5720 5745 5765 5785 5805 5825 5845, ""

$ iw dev
phy#2
Interface wlx00c0caadcb84
ifindex 5
wdev 0x200000001
addr 00:c0:ca:ad:cb:84
ssid Bass
type managed
channel 36 (5180 MHz), width: 80 MHz, center1: 5210 MHz
txpower 20.00 dBm
multicast TXQ:
qsz-byt qsz-pkt flows drops marks overlmt hashcol tx-bytes tx-packets
0 0 0 0 0 0 0 0 0

64 bytes from 192.168.1.1: icmp_seq=60 ttl=64 time=0.863 ms
64 bytes from 192.168.1.1: icmp_seq=61 ttl=64 time=0.553 ms
64 bytes from 192.168.1.1: icmp_seq=62 ttl=64 time=0.609 ms
64 bytes from 192.168.1.1: icmp_seq=63 ttl=64 time=0.566 ms
64 bytes from 192.168.1.1: icmp_seq=64 ttl=64 time=0.535 ms
64 bytes from 192.168.1.1: icmp_seq=65 ttl=64 time=0.597 ms
64 bytes from 192.168.1.1: icmp_seq=66 ttl=64 time=0.967 ms
64 bytes from 192.168.1.1: icmp_seq=67 ttl=64 time=0.559 ms
64 bytes from 192.168.1.1: icmp_seq=68 ttl=64 time=0.565 ms
64 bytes from 192.168.1.1: icmp_seq=69 ttl=64 time=0.513 ms
64 bytes from 192.168.1.1: icmp_seq=70 ttl=64 time=0.588 ms
64 bytes from 192.168.1.1: icmp_seq=71 ttl=64 time=0.601 ms
64 bytes from 192.168.1.1: icmp_seq=72 ttl=64 time=0.599 ms
64 bytes from 192.168.1.1: icmp_seq=73 ttl=64 time=0.604 ms
64 bytes from 192.168.1.1: icmp_seq=74 ttl=64 time=0.492 ms
64 bytes from 192.168.1.1: icmp_seq=75 ttl=64 time=0.568 ms
64 bytes from 192.168.1.1: icmp_seq=76 ttl=64 time=0.591 ms
64 bytes from 192.168.1.1: icmp_seq=77 ttl=64 time=0.513 ms
64 bytes from 192.168.1.1: icmp_seq=78 ttl=64 time=0.521 ms

Well, that was not what I expected. Connecting the adapter seemed to supercharge it. Ping were going through the ACM.

Nevertheless, I have seen various products where using 2 usb modules or adapters was what was needed but I don't understand enough about your project to make any recommendations right now.

[2m]

Well, that was not what I expected. Connecting the adapter seemed to supercharge it. Ping were going through the ACM.

Really interesting results!

Nevertheless, I have seen various products where using 2 usb modules or adapters was what was needed

I was actually also thinking about a very similar setup: use one wifi adapter for connection, and another for background scan. Then background scan information from the second adapter should be fed to first adapter roaming choices. AFAIK wpa_supplicant is responsible for initiating scans and roaming choices. Have you seen such Linux setups before?

[morrownr]

Have you seen such Linux setups before?

I do some consulting on the side and using two adapters for more or less what you are describing is fairly common in some products. Often those doing it use usb modules instead of usb adapters but some do use adapters... however both are usb and use the same drivers.