[V7,0/4] mac80211: add multiple bssid support

Message

Aloka Dixit Jan. 20, 2021, 12:51 a.m. UTC

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

Comments

Johannes Berg Feb. 12, 2021, 9:59 a.m. UTC | #1

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

Johannes Berg Feb. 12, 2021, 9:59 a.m. UTC | #2

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

Aloka Dixit Feb. 22, 2021, 10:41 p.m. UTC | #3

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.