On 6/21/2019 7:14 PM, Denis Kenzior wrote:
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?
hmm. I tried searching in memory... of my email client but to no avail.
I somehow recalled that netlink multicast was not guaranteed to be
delivered/seen by all listeners.
"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 ;)
That's just it, right. This is what Marcel calls the real environment,
but is it. The nl80211 is a kernel API and should that mean that there
must be a managing daemon locking down APIs for other user-space tools
to use. If I want a user-space app to show a radar screen with
surrounding APs using scanning and FTM nl80211 commands it seems now it
has to create a new interface and hope the resources are there for it to
succeed. Where is my freedom in that? If I am using such an app don't
you think I don't accept it could impact the managing daemon.
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 ;)
Probably. One of my concerns was about NL80211_CMD_CONNECT event, but
checking nl80211_send_connect_result() it seems to just send it to the
mlme multicast group regardless SOCKET_OWNER use.
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?
Not saying that. Just saying that the "real environment" is in the eye
of the beholder and it would be nice if there was a way to opt out, but
Marcel seems strongly opposed to it. So there seems no point in
scratching that itch and come up with a patch.
Regards,
Arend
