From: Denis Kenzior <denkenz@gmail.com>
To: Arend Van Spriel <arend.vanspriel@broadcom.com>,
Johannes Berg <johannes@sipsolutions.net>
Cc: linux-wireless@vger.kernel.org
Subject: Re: [PATCH v2 2/3] nl80211: Limit certain commands to interface owner
Date: Fri, 21 Jun 2019 12:14:01 -0500 [thread overview]
Message-ID: <af810765-ba1a-c7ae-abe5-35eef72eb8ce@gmail.com> (raw)
In-Reply-To: <11852f40-67e5-9122-7d82-077bdd0b014a@broadcom.com>
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
next prev parent reply other threads:[~2019-06-21 17:14 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-20 22:07 [PATCH v2 1/3] nl80211: Update uapi for CMD_FRAME_WAIT_CANCEL Denis Kenzior
2019-06-20 22:07 ` [PATCH v2 2/3] nl80211: Limit certain commands to interface owner Denis Kenzior
2019-06-21 8:09 ` Arend Van Spriel
2019-06-21 13:27 ` Marcel Holtmann
2019-06-21 17:14 ` Denis Kenzior [this message]
2019-06-21 21:16 ` Arend Van Spriel
2019-06-21 22:33 ` Denis Kenzior
2019-06-22 13:44 ` Marcel Holtmann
2019-06-24 8:39 ` Arend Van Spriel
2019-06-24 17:36 ` Denis Kenzior
2019-06-20 22:07 ` [PATCH v2 3/3] nl80211: Include wiphy address setup in NEW_WIPHY Denis Kenzior
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=af810765-ba1a-c7ae-abe5-35eef72eb8ce@gmail.com \
--to=denkenz@gmail.com \
--cc=arend.vanspriel@broadcom.com \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).