| Message ID | 20230301090242.1613672-1-quic_xinyling@quicinc.com |
|---|---|
| Headers | show |
| Series | wifi: nl80211: Add support to specify channel width for scan | expand |
On Wed, 2023-03-01 at 17:02 +0800, Xinyue Ling wrote: > nl80211_trigger_scan() processes scan request netlink attributes, > defined in enum nl80211_attrs, and fills struct > cfg80211_scan_request *request. > > Currently there is no logic to fill this member: > enum nl80211_bss_scan_width scan_width; Right, noticed that too some time ago while working on MLO. > We have a requirement to fill this member for drone use cases, in > which drone controller needs to scan and connect to drone in 5 MHz > or 10 MHz channel width (may support other channel widths lower > than 20 MHz later). :-( > The following series of patches is the implementations of above two > options. In order to make them a series, a revert patch is included, > which can be ignored. Please review and decide which option is more > reasonable and acceptable. I'm not sure this matters so much right now ... either works. I suspect a new attribute might be nicer (fsvo "nicer"). However, all this stuff is currently completely broken in mac80211. Are you wanting to use it with mac80211? ieee80211_vif_get_shift() is fairly much broken (deflink), and even if we don't expect to use MLO with narrow channels, it's still a huge mess. In fact, had I had enough time, I'd have removed all that code entirely from mac80211 already, since it's clearly unreachable. There's nothing that can ever select a narrow-band BSS since you can't actually scan that way as you noticed too. So ... for your use case: 1) are you going to use mac80211? 2) if not, which (upstream!) driver are you going to use? 3) if yes, are you willing to dig through mac80211 and clean up all that narrow-band code: - to make sure it interacts well with MLO (even if it doesn't _support_ MLO), - to define it correctly wrt. what's supported such as HT/VHT/HE/EHT with narrow channels? How would that even work? I guess none of those - unless we're dealing with vendor extensions? - if we're dealing with vendor extensions here, anyone actually willing to commit to those and document them properly outside of just having a half-baked implementation? So honestly, I'm not even going to look at these patches before I can get some answers on this, because while it may work for your use case right now, it's clearly a mess. For example, nothing prevents you even from trying to create MLO out of a narrow-band and regular BSS, other than that no AP would likely beacon that way ... Hopefully!! But I don't think we should just hope that no AP does this and that wpa_s is smart enough. johannes
nl80211_trigger_scan() processes scan request netlink attributes, defined in enum nl80211_attrs, and fills struct cfg80211_scan_request *request. Currently there is no logic to fill this member: enum nl80211_bss_scan_width scan_width; We have a requirement to fill this member for drone use cases, in which drone controller needs to scan and connect to drone in 5 MHz or 10 MHz channel width (may support other channel widths lower than 20 MHz later). Unfortunately there is not an existing attribute in enum nl80211_attrs that has enum nl80211_bss_scan_width semantics. The only attribute which has those semantics is NL80211_BSS_CHAN_WIDTH in enum nl80211_bss, and of course we can't mix attributes from different enums in a netlink command, at least not at the same nesting level. enum nl80211_attrs does define another attribute, NL80211_ATTR_CHANNEL_WIDTH, but it has enum nl80211_chan_width semantics. In order to support the requirement to fill the scan_width with an enum nl80211_bss_scan_width value we seem to have two options: 1) Use NL80211_ATTR_CHANNEL_WIDTH and convert from enum nl80211_chan_width semantics to enum nl80211_bss_scan_width semantics when filling struct cfg80211_scan_request *request. 2) Introduce a new NL80211_ATTR_SCAN_CHANNEL_WIDTH attribute to enum nl80211_attrs that has enum nl80211_bss_scan_width semantics. The following series of patches is the implementations of above two options. In order to make them a series, a revert patch is included, which can be ignored. Please review and decide which option is more reasonable and acceptable. Xinyue Ling (4): nl80211: Add 4/8/16 MHz BSS control channel width definitions wifi: nl80211: Add support to specify channel width for scan (option 1) Revert "wifi: nl80211: Add support to specify channel width for scan (option 1)" wifi: nl80211: Add support to specify channel width for scan (option 2) include/net/cfg80211.h | 6 ++++++ include/uapi/linux/nl80211.h | 34 ++++++++++++++++++++++++++++++++-- net/wireless/nl80211.c | 14 ++++++++++++++ 3 files changed, 52 insertions(+), 2 deletions(-)