This patchset adds support for multiple BSSID and
enhanced multi-BSSID advertisements.
This version adds few calls to kfree() in nl80211.c which were
missing in V6.
John Crispin (4):
nl80211: add basic multiple bssid support
mac80211: add multiple bssid support to interface handling
mac80211: add multiple bssid/EMA support to beacon handling
mac80211: CSA on non-transmitting interfaces
include/net/cfg80211.h | 47 ++++++
include/net/mac80211.h | 116 +++++++++++++-
include/uapi/linux/nl80211.h | 66 ++++++++
net/mac80211/cfg.c | 181 ++++++++++++++++++++--
net/mac80211/debugfs.c | 1 +
net/mac80211/ieee80211_i.h | 2 +
net/mac80211/iface.c | 6 +
net/mac80211/tx.c | 189 ++++++++++++++++++++---
net/wireless/nl80211.c | 282 +++++++++++++++++++++++++++--------
9 files changed, 796 insertions(+), 94 deletions(-)
base-commit: 0ae5b43d6dde6003070106e97cd0d41bace2eeb2
--
2.25.0
Hi,
> John Crispin (4):
> nl80211: add basic multiple bssid support
> mac80211: add multiple bssid support to interface handling
> mac80211: add multiple bssid/EMA support to beacon handling
> mac80211: CSA on non-transmitting interfaces
As much as I hate to send this back to you ...
I don't understand how you can not have an nl80211 feature flag for AP-
side multi-BSSID support, yet have a mac80211-level feature flag?
For STA side we could get away with it because we present all the BSSes
in cfg80211's scan results, and even a version of wpa_supplicant that's
not aware of multi-BSSID should be able to pick one of the non-
transmitting BSSes and connect to it.
But here? I don't understand how that'd be possible.
Also, are the interface limits (# of AP interfaces) even sufficient, or
should there be different limits for non-transmitting? I could imagine
that it'd be easier to have more interfaces if they're non-transmitting,
since then you don't have to deal with more beacons but only more MAC
addresses.
So from that POV this seems rather lacking the necessary bits to be able
to confidently use it from userspace?
johannes
On Fri, 2021-02-12 at 10:59 +0100, Johannes Berg wrote:
> Hi,
>
> > John Crispin (4):
> > nl80211: add basic multiple bssid support
And since I rebased that already - here's a copy:
https://p.sipsolutions.net/59ffc0425476edfe.txt
johannes
On 2021-02-12 01:59, Johannes Berg wrote:
> Hi,
>
>> John Crispin (4):
>> nl80211: add basic multiple bssid support
>> mac80211: add multiple bssid support to interface handling
>> mac80211: add multiple bssid/EMA support to beacon handling
>> mac80211: CSA on non-transmitting interfaces
>
> As much as I hate to send this back to you ...
>
> I don't understand how you can not have an nl80211 feature flag for AP-
> side multi-BSSID support, yet have a mac80211-level feature flag?
>
> For STA side we could get away with it because we present all the BSSes
> in cfg80211's scan results, and even a version of wpa_supplicant that's
> not aware of multi-BSSID should be able to pick one of the non-
> transmitting BSSes and connect to it.
>
> But here? I don't understand how that'd be possible.
>
Will add nl80211 feature flags for MBSSID and EMA.
> Also, are the interface limits (# of AP interfaces) even sufficient, or
> should there be different limits for non-transmitting? I could imagine
> that it'd be easier to have more interfaces if they're
> non-transmitting,
> since then you don't have to deal with more beacons but only more MAC
> addresses.
>
This implementation allows a single MBSSID-set, so only one transmitting
interface per wiphy.
Even if non-transmitting don't have beacons associated, drivers will
have
limit depending on contexts allocated for other interface
characteristics.
Hence these limits are accepted using 'max_num_vaps' and
'max_profile_periodicity'.
> So from that POV this seems rather lacking the necessary bits to be
> able
> to confidently use it from userspace?
>
> johannes
Next version will have feature flags as well as max VAPs and profile
periodicity exposed to application.