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>
 <6e723a78-db68-8ffb-986a-4a3961107f72@gmail.com>
 <1a56c641eaa03c99dc9a90208902d8bb1ca1b0aa.camel@sipsolutions.net>
 <048b81db-8e92-7fe0-1f5c-3b6f9ea1a1f1@gmail.com>
 <366b1599374240ef194bf7eb6e1e47a8b675f474.camel@sipsolutions.net>
From:   Denis Kenzior <denkenz@gmail.com>
Message-ID: <978dab89-343a-3fc9-dbdb-7acf87d735ca@gmail.com>
Date:   Mon, 24 Feb 2020 13:35:51 -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: <366b1599374240ef194bf7eb6e1e47a8b675f474.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,

>> So from a holistic point of view, taking kernel + userspace into
>> account, what is wrong with letting control port transport preauth
>> frames if that saves a bunch of resources (and possibly wakeups if the
>> bpf is setup badly) on the system?
> 
> If you paint it that way, it doesn't seem like there's anything wrong
> with it, does it?
> 
> But not sure that's the right color - you could apply that precise same
> argument to, say, transporting DHCP packets over the same path? I think
> you'd agree that doesn't make it right?

But I'm not, and I don't think the argument for DHCP is anywhere as 
strong.  DHCP is typically handled outside of the wifi management daemon 
(though it can be done inside) and is usually something that is very 
much separate from WiFi details regardless of where it lives.

> 
> Just because preauth is a wifi related protocol doesn't mean we should
> treat it in a wifi control path.

But it seems like the benefits outweigh the drawbacks?  At least we have 
been super happy with how control port works for us.  If you take the 
pre-auth path away, I'm really not sure there's any point in (at least 
for us) keeping support for the control port path.

> 
>> Also, the question is what changed your mind?  I asked you specifically
>> if preauth should be included in the control port API and you thought it
>> was a good idea at the time?
> 
> I don't really remember that, but perhaps? Mostly I guess the discussion
> on the hostap list now, I suppose.

I'm not subscribed there.  A synopsis of the discussion (or 
linux-wireless CC) would have been nice.

Regards,
-Denis