Hi Arend,
On 06/21/2019 03:09 AM, Arend Van Spriel wrote:
On 6/21/2019 12:07 AM, Denis Kenzior wrote:
If the wdev object has been created (via NEW_INTERFACE) with
SOCKET_OWNER attribute set, then limit certain commands only to the
process that created that wdev.
This can be used to make sure no other process on the system interferes
by sending unwanted scans, action frames or any other funny business.
The flag is a good addition opposed to having handlers deal with it.
However, earlier motivation for SOCKET_OWNER use was about netlink
multicast being unreliable, which I can agree to. However, avoiding
??? I can't agree to that as I have no idea what you're talking about
:) Explain? SOCKET_OWNER was introduced mainly to bring down links /
scans / whatever in case the initiating process died. As a side effect
it also helped in the beginning when users ran iwd + wpa_s
simultaneously (by accident) and all sorts of fun ensued. We then
re-used SOCKET_OWNER for running EAPoL over NL80211. But 'multicast
unreliability' was never an issue that I recall?
"funny business" is a different thing. Our testing infrastructure is
doing all kind of funny business. Guess we will need to refrain from
So you're going behind the managing daemon's back and messing with the
kernel state... I guess the question is why? But really, if wpa_s
wants to tolerate that, that is their problem :) iwd doesn't want to,
nor do we want to deal with the various race conditions and corner cases
associated with that. Life is hard as it is ;)
using any user-space wireless tools that use the SOCKET_OWNER attribute,
but how do we know? Somehow I suspect iwd is one to avoid ;-) I have yet
I guess you will be avoiding wpa_s since that one uses SOCKET_OWNER too ;)
to give iwd a spin, but this SOCKET_OWNER strategy kept me from it.
Maybe iwd could have a developer option which disables the use of the
SOCKET_OWNER attribute.
Okay? Not sure what you're trying to say here? I'd interpret this as
"You guys suck. I'm taking my ball and going home?" but I hope this
isn't what you're saying?
Regards,
-Denis
