Open terrysimons opened 3 years ago
terrysimons
commented
3 years ago As a datapoint, it's possible to "unstick" this behavior, by re-issuing:
$ sudo iw dev wlan1 set monitor noneThen after starting tcpdump again with sudo tcpdump -i wlan1, the issue will occur again once the channel hop happens.
Rinse and repeat these two commands to see the failure reproduce.
terrysimons
commented
3 years ago The two sed lines I used were updated. I fixed the original post to include CONFIG_PLATFORM_ARM64 = y as the correct way to build the driver on Ubuntu 20.10.
terrysimons
commented
3 years ago Oops, accidentally clicked "Close with comment". This issue is still valid.
It looks like there's a driver bug in the rtl8814au driver related to the chip switching channels, and then coming back to the original channel. It seems to be the case that wpa_supplicant is possibly causing the channel switching, as I can't reproduce the problem with wpa_supplicant removed from the system, but the real issue is that the driver starts losing certain types of frames once it re-settles back to its original sniffing channel.
When sniffing, I noticed that initially, data frames would be coming in, but then after a while (~1-2 minutes) I no longer see data frames. I thought at first that it was possibly a bug where data frames were getting dropped, but it looks like the radio is changing channels on me and then switching back, and when it switches back I only see Action frames, Probe Requests, and a few other types of management frames.
I can consistently reproduce this, and once the driver gets in this state, any subsequent tcpdump (or wireshark) sniff attempts fail to produce data frames (and possibly others?)
I thought I had disabled wpa_supplicant with /etc/dhcpcd.conf using:
But at least on Ubuntu 20.10 it seems like removing wpa_supplicant with
sudo dpkg -r --force-depends wpasupplicantis necessary, so I'll have to play with this a bit and see if there's a different way to do per-interface disablement of wpa_supplicant on Ubuntu 20.10.Any idea what might be causing the driver/wpa_supplicant to go do some scans on other channels and come back? Is there a way to disable this behavior?
I'm running Ubuntu 20.10 64-bit on a Raspberry Pi 4 8GB configuration.
This is 100% reproducible for me on Ubuntu 20.10 64-bit using commit hash:
commit 27d2344264f774dd2add19d4139dfc07985d6ada (HEAD -> v5.8.5.1, origin/v5.8.5.1, origin/HEAD)I'm building the driver with:
As mentioned above, removing wpa_supplicant from the system seems to fix this, but the sniffing behavior seems like a bug in the driver to me, which just happens to be tickled by whatever wpa_supplicant is doing.
Here's an example of me sniffing along merrily on freq 5785 @ 80MHz, with data frames coming in, and then the radio does some sort of hopscotch around on some other channels, and then comes back to 5785, but now I'm no longer receiving data frames.
Notice how at 15:28:16.763574, the radio jumps over to 2412 MHz, then a bunch of other 2.4Ghz channels, then a bunch of other 5GHz channels before landing on 5785 again, but when it comes back to 5785, I'm no longer seeing data frames.