Hi Arend,
On 06/24/2019 03:39 AM, Arend Van Spriel wrote:
On 6/22/2019 3:44 PM, Marcel Holtmann wrote:
Hi Arend,
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.
if you are operating on a shared radio resource you have to have some
way of ensuring that nobody steals resources from you. Having an
external application that will also use scanning and other off-channel
operation will result in a bad experience. Especially if it involves
scanning. Currently we still have 3 or more parties triggering
scanning on nl80211. Essentially they are now fighting for radio time.
You have wpa_supplicant scanning, you have NetworkManager scanning and
you have the UI scanning. Now adding just another application that
just scans at its decided time location / direction finding is not
helping the situation.
My app was just a hypothetical example. I understand your conundrum, but
my point was that you can not know how a system is configured. Now for
the SOCKET_OWNER I should say it does not provide you any guarantees. At
best it improves your chances. With the nl80211 API being as it is, you
can not rule out multiple application controlling the same device. The
virtual interfaces can be guarded with SOCKET_OWNER, but in the end
+1, SOCKET_OWNER is a band-aid. But in the end this is a fairly simple
change. So we can have the managing daemon destroy any existing wdevs
and re-create them with SOCKET_OWNER set (can we get brcmfmac to support
this please?). This at least gives us a chance that nothing will
inadvertently cause interference. It won't stop other processes from
creating other wdevs or other funny business, but that is currently much
more rare anyway. In case it really becomes a problem, we can at least
say "Don't hold it that way."
there is still one physical device and only if you are lucky you may
come across a device with two physical radios, but most of them just
have one. If you really want to be in control we should allow only one
socket or at least only one "control" socket.
+1. I've been saying this for a while, there should only be a single
controlling socket/process, or at least an option for something like
that. But the current nl80211 design makes this quite hard. Hopefully
the recognition that this is needed will gain traction, until then we're
stuck with band-aids.
If our kernel cfg80211 / nl80211 would be smart enough to handle these
concurrent tasks, I would have little objection to let all clients do
whatever they want, but we don’t have that. I do not want an external
application messing with my planned radio time. And frankly if I am in
the middle of roaming, I don’t want to be delayed because some fancy
radar looking UI decides to start a full spectrum scan or blocks us
via an action frame that times out.
The have been some efforts to handle concurrent use. For scheduled scan
concurrency was added and critical proto primitives allow to temporarily
disable scans when user-space needs it, eg. for EAPOL or DHCP exchange.
Which only a single driver seems to support, unfortunately.
Regards,
-Denis
With iwd we are moving towards the direction that we are utilizing the
information from access points and surrounding networks to
intelligently scan and reduce the time spent scanning to a minimum.
For us that is the way to improve WiFi experience for Linux.
We have been through this with Bluetooth already years ago. You need a
central daemon that watches out for your radio utilization. Doing
anything behind the back of such a daemon is not going to work out
long term. Same applies to 2G/3G/LTE where even more tasks need to be
managed. And even wpa_supplicant has an internal mutex to control
radio time.
Right. Given how nl80211 works today the only real control of radio time
would need to be done in kernel space or go for the one "control" socket
approach.
Regards,
Arend
