On 5/8/2018 2:19 PM, Johannes Berg wrote:
On Tue, 2018-05-08 at 14:18 +0200, Arend van Spriel wrote:
On 5/7/2018 9:19 PM, Johannes Berg wrote:
On Sun, 2018-04-29 at 20:30 +0200, Andrew Zaborowski wrote:
On 28 April 2018 at 15:07, Kalle Valo <kvalo@xxxxxxxxxxxxxx> wrote:
Andrew Zaborowski <andrew.zaborowski@xxxxxxxxx> writes:
Reject NL80211_CMD_DISCONNECT, NL80211_CMD_DISASSOCIATE,
NL80211_CMD_DEAUTHENTICATE and NL80211_CMD_ASSOCIATE commands
from clients other than the connection owner set in the connect,
authenticate or associate commands, if it was set.
The main point of this check is to prevent chaos when two processes
try to use nl80211 at the same time, it's not a security measure.
The same thing should possibly be done for JOIN_IBSS/LEAVE_IBSS and
START_AP/STOP_AP.
s-o-b missing.
True, thanks. Also I was going to send this as an RFC.
Looks fine to me, please resend if you want it in :)
Do we really want this? Is the referred chaos hypothetical or an actual
issue. Nothing stops me from doing an 'ifconfig down' so why should 'iw
disconnect' be any different. As far I can tell it does not affect my
testing environment, but particularly in such use-cases I can expect
issues adopting this change, which is also hypothetical of course ;-)
Yeah, it's a good question. But it might help with inadvertent issues,
like starting wpa_s which immediately disconnects if it finds something
connected. If that fails, perhaps you have a better chance of noticing
the error?
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 ;-)
Regards,
Arend
