Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Sender: alokad=codeaurora.org@mg.codeaurora.org
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Date:   Mon, 22 Feb 2021 14:41:01 -0800
From:   Aloka Dixit <alokad@codeaurora.org>
To:     Johannes Berg <johannes@sipsolutions.net>
Cc:     linux-wireless@vger.kernel.org
Subject: Re: [PATCH V7 0/4] mac80211: add multiple bssid support
In-Reply-To: <c3b48c141c763e0cc1beb74482cd0bb4fbc546aa.camel@sipsolutions.net>
References: <20210120005120.32424-1-alokad@codeaurora.org>
 (sfid-20210120_015542_749517_52354F67)
 <c3b48c141c763e0cc1beb74482cd0bb4fbc546aa.camel@sipsolutions.net>
Message-ID: <64f490e2a559a0ed33c59d0fc7326582@codeaurora.org>
User-Agent: Roundcube Webmail/1.3.9
Precedence: bulk

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.