From: Nicolas Cavallari <[email protected]>
Set the NL80211_EXT_FEATURE_DEL_IBSS_STA if the interface support IBSS
mode, so that stations can be reset from user space.
mac80211 already deletes stations by itself, so mac80211 drivers must
already support this.
This has been successfully tested with ath9k.
Signed-off-by: Nicolas Cavallari <[email protected]>
---
v3: spelling fixes in commit message.
---
net/mac80211/main.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index 944e86da5c65..bc7fd67dc987 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -1081,6 +1081,10 @@ int ieee80211_register_hw(struct ieee80211_hw *hw)
NL80211_EXT_FEATURE_EXT_KEY_ID);
}
+ if (local->hw.wiphy->interface_modes & BIT(NL80211_IFTYPE_ADHOC))
+ wiphy_ext_feature_set(local->hw.wiphy,
+ NL80211_EXT_FEATURE_DEL_IBSS_STA);
+
/*
* Calculate scan IE length -- we need this to alloc
* memory and to subtract from the driver limit. It
--
2.25.1
On 05.03.20 14:57, Nicolas Cavallari wrote:
> From: Nicolas Cavallari <[email protected]>
>
> Set the NL80211_EXT_FEATURE_DEL_IBSS_STA if the interface support IBSS
> mode, so that stations can be reset from user space.
>
> mac80211 already deletes stations by itself, so mac80211 drivers must
> already support this.
>
> This has been successfully tested with ath9k.
>
> Signed-off-by: Nicolas Cavallari <[email protected]>
>
> ---
> v3: spelling fixes in commit message.
> ---
> net/mac80211/main.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/net/mac80211/main.c b/net/mac80211/main.c
> index 944e86da5c65..bc7fd67dc987 100644
> --- a/net/mac80211/main.c
> +++ b/net/mac80211/main.c
> @@ -1081,6 +1081,10 @@ int ieee80211_register_hw(struct ieee80211_hw *hw)
> NL80211_EXT_FEATURE_EXT_KEY_ID);
> }
>
> + if (local->hw.wiphy->interface_modes & BIT(NL80211_IFTYPE_ADHOC))
> + wiphy_ext_feature_set(local->hw.wiphy,
> + NL80211_EXT_FEATURE_DEL_IBSS_STA);
> +
> /*
> * Calculate scan IE length -- we need this to alloc
> * memory and to subtract from the driver limit. It
Hi Nicolas,
I took these patches for a thorough spin offshore (combined with your
quick wpa_sup change)
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?
Thanks,
Koen
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.
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