| Message ID | 20210120005120.32424-1-alokad@codeaurora.org |
|---|---|
| Headers | show |
| Series | mac80211: add multiple bssid support | expand |
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.