| Message ID | 20230110110524.511258-1-vincent@systemli.org (mailing list archive) |
|---|---|
| State | Rejected |
| Delegated to: | Johannes Berg |
| Headers | show |
| Series | wifi: mac80211: add support for scanning in ap mode | expand |
On Tue, 2023-01-10 at 12:05 +0100, Nick Hainke wrote: > OpenWRT has shipped a patch since 2011 that allows it to perform a scan > in AP mode, whether it is supported by the driver or not. In certain > situations, it may be desirable to scan an interface that is currently > in AP mode regardless of whether frames are missed. The patch adds a > module parameter "allow_ap_scan" that, if set to true, allows the behavior > described above. > I must say - not really in favour of throwing around random module parameters like that :) johannes
Thanks for your feedback. Can you suggest a better way to do this? Bests Nick On 1/10/23 12:07, Johannes Berg wrote: > On Tue, 2023-01-10 at 12:05 +0100, Nick Hainke wrote: >> OpenWRT has shipped a patch since 2011 that allows it to perform a scan >> in AP mode, whether it is supported by the driver or not. In certain >> situations, it may be desirable to scan an interface that is currently >> in AP mode regardless of whether frames are missed. The patch adds a >> module parameter "allow_ap_scan" that, if set to true, allows the behavior >> described above. >> > I must say - not really in favour of throwing around random module > parameters like that :) > > johannes
On Tue, 2023-01-10 at 12:18 +0100, Nick wrote: > Thanks for your feedback. Can you suggest a better way to do this? > Well there already is NL80211_SCAN_FLAG_AP? johannes
On Tue, 2023-01-10 at 12:19 +0100, Johannes Berg wrote: > On Tue, 2023-01-10 at 12:18 +0100, Nick wrote: > > Thanks for your feedback. Can you suggest a better way to do this? > > > > Well there already is NL80211_SCAN_FLAG_AP? > Oh sorry you want it independent of the driver. But why? This was primarily a thing for "does the firmware even support this". So really then your driver should set it? johannes
Sorry, I made a mistake. NL80211_SCAN_FLAG_AP seems to do everything I want. Initially I thought there was something special about the "NL80211_FEATURE_AP_SCAN" that was also needed, since it is not being set by the ath9k. Also, the OpenWrt patch does not test for "NL80211_FEATURE_AP_SCAN", so I thought it was necessary to skip this check as well. However, I just noticed that this flag is set for ath9k in mac80211. I have just tested it again with ath9k (iw dev wlan0 scan ap-force) and it works as expected. As far as I know, tools like iwinfo do not include this "force" option. OpenWrt's Luci interface heavily relies on iwinfo. So far this is not an issue, as the default behavior of mac80211 in OpenWrt currently allows scanning regardless of "NL80211_FEATURE_AP_SCAN" or "NL80211_SCAN_FLAG_AP". So if I want to get rid of this downstream patch I have to rewrite the iwinfo logic and maybe always include NL80211_SCAN_FLAG_AP as default. Thank you very much for your time and feedback. Bests Nick On 1/10/23 12:20, Johannes Berg wrote: > On Tue, 2023-01-10 at 12:19 +0100, Johannes Berg wrote: >> On Tue, 2023-01-10 at 12:18 +0100, Nick wrote: >>> Thanks for your feedback. Can you suggest a better way to do this? >>> >> Well there already is NL80211_SCAN_FLAG_AP? >> > Oh sorry you want it independent of the driver. > > But why? This was primarily a thing for "does the firmware even support > this". > > So really then your driver should set it? > > johannes
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c index 8f9a2ab502b3..04730fb0f621 100644 --- a/net/mac80211/cfg.c +++ b/net/mac80211/cfg.c @@ -2723,6 +2723,9 @@ static int ieee80211_scan(struct wiphy *wiphy, */ fallthrough; case NL80211_IFTYPE_AP: + /* Support scanning in AP mode regardless of driver support. */ + if (allow_ap_scan) + break; /* * If the scan has been forced (and the driver supports * forcing), don't care about being beaconing already. diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h index 63ff0d2524b6..d48c7dd00dd4 100644 --- a/net/mac80211/ieee80211_i.h +++ b/net/mac80211/ieee80211_i.h @@ -2566,4 +2566,7 @@ ieee80211_eht_cap_ie_to_sta_eht_cap(struct ieee80211_sub_if_data *sdata, const struct ieee80211_eht_cap_elem *eht_cap_ie_elem, u8 eht_cap_len, struct link_sta_info *link_sta); + +extern bool allow_ap_scan; + #endif /* IEEE80211_I_H */ diff --git a/net/mac80211/main.c b/net/mac80211/main.c index 846528850612..c33d99717cd0 100644 --- a/net/mac80211/main.c +++ b/net/mac80211/main.c @@ -33,6 +33,11 @@ #include "led.h" #include "debugfs.h" +bool allow_ap_scan; +module_param(allow_ap_scan, bool, 0644); +MODULE_PARM_DESC(allow_ap_scan, + "Support scanning in AP mode regardless of driver support."); + void ieee80211_configure_filter(struct ieee80211_local *local) { u64 mc;
OpenWRT has shipped a patch since 2011 that allows it to perform a scan in AP mode, whether it is supported by the driver or not. In certain situations, it may be desirable to scan an interface that is currently in AP mode regardless of whether frames are missed. The patch adds a module parameter "allow_ap_scan" that, if set to true, allows the behavior described above. Tested-on: TP Link Archer C7 V2 (Qualcomm Atheros QCA9558, Qualcomm Atheros QCA9880-BR4A) with OpenWrt Linux 5.15.86 Signed-off-by: Nick Hainke <vincent@systemli.org> --- net/mac80211/cfg.c | 3 +++ net/mac80211/ieee80211_i.h | 3 +++ net/mac80211/main.c | 5 +++++ 3 files changed, 11 insertions(+)