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
