Re: [PATCH] nl80211: Reject disconnect commands except from conn_owner

[Denis Kenzior <denkenz@gmail.com>]

Hi Arend,

On 05/22/2018 05:39 AM, Arend van Spriel wrote:
> On 5/8/2018 5:05 PM, Denis Kenzior wrote:
>> Hi Arend,
>>
>>>
>>> Sure. I guess we all have been there kicking of wpa_s and discovering
>>> there is already one running in the background. I am just a bit
>>> squeamish to change the behavior like this. Hmmmm. Is wpa_s already
>>> using SOCKET_OWNER. If so, I might create a patch to opt-out for that
>>> so people can knowingly choose chaos ;-)
>>>
>>
>> wpa_s is using SOCKET_OWNER these days.  However, with the introduction
>> of Control Port over NL80211, just getting rid of SOCKET_OWNER might not
>> be that easy.
> 
> I have a regression test script employing py80211 which listens for 
> connect event. Right now I am using an older wpa_s, but the above will 
> screw it up.

So it is still early in the morning for me and you might have to talk 
slower.  But let me take a stab anyway :)

What will screw up?  The connect event is always multicast, so you 
should still receive it regardless of SOCKET_OWNER / Control Port over 
NL80211.

> 
> If I recall correctly the mlme notification needed to be unicast, 
> because multicast was not 100% reliable, right? Would it be acceptable 
> to send unicast to the socket owner and still do the multicast or are we 
> already doing that? If not, that would fix my imminent issue.
> 

Control Port events are only unicast to the application that is the 
SOCKET_OWNER.  E.g. either wpa_s or iwd.  They are never multicast as 
nobody else could make sense of them anyway due to lack of passphrase / 
nonces.

The other 'regular' events like Disconnect, Connect, etc are still 
multicast.  What this patch does is prevents some app from rudely coming 
in and sending a Disconnect on an interface which is being managed by 
another process, e.g. iwd or wpa_s, that has set the SOCKET_OWNER flag.

Regards,
-Denis