Received-SPF: pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [PATCH 1/2] Revert "mac80211: support
 NL80211_EXT_FEATURE_CONTROL_PORT_OVER_NL80211_MAC_ADDRS"
To:     Johannes Berg <johannes@sipsolutions.net>,
        linux-wireless@vger.kernel.org
Cc:     Markus Theil <markus.theil@tu-ilmenau.de>
References: <20200224101910.b87da63a3cd6.Ic94bc51a370c4aa7d19fbca9b96d90ab703257dc@changeid>
 <c9fba32a-6959-a93a-3119-23915053538c@gmail.com>
 <53190ece697ab7d9e83fdd667eaf9e05a4418193.camel@sipsolutions.net>
From:   Denis Kenzior <denkenz@gmail.com>
Message-ID: <6e723a78-db68-8ffb-986a-4a3961107f72@gmail.com>
Date:   Mon, 24 Feb 2020 12:26:05 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <53190ece697ab7d9e83fdd667eaf9e05a4418193.camel@sipsolutions.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-wireless-owner@vger.kernel.org
Precedence: bulk

Hi Johannes,

On 2/24/20 12:26 PM, Johannes Berg wrote:
> On Mon, 2020-02-24 at 10:56 -0600, Denis Kenzior wrote:
> 
>> So to me this patch set seemed like a good idea...  We (iwd) don't have
>> plans to support pre-auth in AP mode in the near future, so this revert
>> doesn't really affect us.  I do wonder what is the actual concern to
>> warrant a revert?
> 
> These are two entirely different things, preauth is simply real data as
> far as the local system is concerned. It's not related to controlled
> port operation at all, which this nl80211 API is about.

I can understand this argument, but from what I remember, one of the 
goals of the control port API was to make this legacy 'special data 
packet' processing unnecessary for userspace.  In other words userspace 
wouldn't need to establish raw sockets.  Hence my question, what is the 
actual concern here?

> 
> FWIW, you may have seen Markus's patch to remove preauth from the RX as
> well, this won't work as is, but I'm still a bit on the fence as to
> whether I'll force you into the right model or not (i.e. clear the
> existing capability bit in mac80211, and introduce a new one that
> doesn't report preauth over nl80211). For RX, however, the difference
> isn't really that much of a big deal, so maybe just make it optional.

We're actually quite happy with the current model.  So I'd like to keep 
things as they are.

Regards,
-Denis