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
