On 08.04.20 16:31, Nicolas Cavallari wrote:
On 08/04/2020 13:56, Koen Vandeputte wrote:
Quick test setup overview:
- Device mounted on top of a vessel, sailing around in windfarms.
- Lots of turbines are equiped with 4x 90deg sectors
- 802.11n HT40 2x2 custom mesh over IBSS, using Dynack
- As the vessel moves around, IBSS links are continuously dropped and
re-added throughout the field
- Output of my app, fyi: https://pastebin.com/raw/vtZSwHC9
I've made 2 identical builds, one containing your patches and one without.
When your patches are used:
--> On devices with multiple radio's, all radio's went deaf within a few
minutes without any notice in logs.
--> Only a reboot solved the issue but everything goes deaf again within
a few minutes. (after dropping/adding some links)
Any idea?
I would highly suspect the hasty wpa_supplicant patch more than the
kernel patches.
I suppose you don't have any wpa_supplicant verbose logs ? (with the -dd
option).
I don't have physical access to any hardware given the current crisis,
but if you could tell which kernel and wpa_supplicant version you
applied the patch on, and whether you took the patches from the mailing
list or from git including the cleanup patches.
Also, which driver/card did you use ? I mainly tested this with ath9k
with ar93xx.
hw used:
1) (moving)
- cns3xxx board (GW2388)
- 4x pci ar9220 (ath9k)
2)
- imx6
- 2x ar93xx (ath9k)
Sw:
OpenWrt 19.07
Kernel: 4.14.174
mac80211: 4.19.112
wpa sup: 2.9
The timeslots to play are short, so I cannot easily test manually for
extra verbosity using wpa_sup.
Using tcpdump shows EAPOL packets being exchanged but I guess it fails
somewhere there.
I used the kernel patches from mailinglist (V3).
If you could cook up a clean patch properly implementing the required
bits over there, I would be happy to test it again.
Regards,
Koen
