On Thu, 2018-01-04 at 20:22 +0100, Marcel Holtmann wrote: > Hi Thomas, > > > > I am in favor of address randomization even while it has limited > > > affect, but at least for background scanning it is useful. > > > However > > > doing this via RTNL is causing a weird layer violation and all > > > sorts > > > of potential races and issues. This needs to be done with full > > > awareness of cfg80211 and thus via nl80211. So iwd should do it. > > > And > > > iwd should just expose an on/off switch for WiFi Privacy. > > > > TL;DR: the policy of which MAC address to use (and when) is > > flexible > > and present in NetworkManager configuration. And it's more then a > > simple randomize on/off switch. > > > > === > > A smaller reason is, that some people have strong opinions and > > consider > > important which bits of the address to scramble (and choose a well > > known manufacturer OUI)[1]. > > I personally don't agree with the importance of such > > considerations, > > but I'd like NetworkManager to be the first choice for people with > > this > > particular need -- regardless of whether this need is real or only > > perceived. > > In NM you can configure how the bits are scrambled very flexible. > > Both > > while scanning[2] and while being associated[3]. > > > > More interesting is, I don't only want to have a random MAC address > > while scanning, but also while being associated. My permanent MAC > > address should never ever be reveiled. > > But a new random MAC address on each new association isn't exactly > > what you > > want either, because then I get a new IP address from DHCP each > > time and have > > to redo captive portal login. > > So, I want for each of my Wi-Fi profiles a different, stable MAC > > address. Actually, for public networks like a hotel, I want to use > > a > > stable MAC address for a limited amount of time. The example in [4] > > show how to do that in NM. > > === > > I have nothing against an option that says generate a new MAC address > for this SSID and keep using it from that time forward.
If I understand correctly, you agree that the MAC address depends on
the profile.
> It is a bit counterproductive if nl80211 doesn’t allow to specify the
> MAC address for association. Since powering down WiFi, changing the
> address and powering back up is something that I am strictly against.
>
> So if these things are what people really want, then neither NM nor
> iwd should actually do the heavy lifting for it. It should be done by
> the wireless stack in the kernel.
Ok, whatever works best.
> > > That said iwd should cope Ok with the MAC address changing behind
> > > its
> > > back if it receives the RTNL notification (RTM_NEWLINK) if it
> > > isn't
> > > connected. It always updates it's copy of the address on a
> > > RTM_NEWLINK so the race condition shouldn't be present I suppose.
> >
> > I would think so too. NM change the MAC address via RTNL only while
> > scanning, early during activation, and late during deactivation.
> > As the wireless daemon does/should not autoactivate the device
> > against
> > NM's wish and NM determines that the device is deactivated only
> > after
> > an event from iwd.
> > Hence, there shouldn't be a race of NM interfering while being
> > connected. The race is only while scanning and iwd should just cope
> > with that.
> >
> > Alternatively/additionally, a SetMacAddress() D-Bus call would
> > avoid
> > any race and allow to leave the decision which address to user to
> > somebody closer to the user.
>
> It will not be as simple as that. You need to leave iwd with the
> decision making for connecting to known WiFi networks. It just isn’t
> as dumb as wpa_supplicant and from a NM perspective, you should be
> doing as little as you do with BlueZ or oFono.
>
> This means iwd needs to be told what to do and not just an address.
> It doesn’t matter if it is via a D-Bus call or RTNL. iwd remembers
> known networks and will connect to them if they are in range, roam
> automatically and also switch networks if it makes sense. That means
> any randomization policy would have to be executed inside iwd and not
> outside. As stated above, if you want different MAC addresses per
> SSID, then that needs to be inside iwd.
>
> So many things in the wpa_supplicant design led to “hacks” outside to
> add features and that really has to stop. It is not maintainable and
> the corner cases and race condition this architecture causes is just
> crazy.
For NM, at each moment not all its connection profiles are candidate
for connecting automatically. The list of which profiles can be
autoactivated depends on NM internal state, for example
- is the profile even configured to allow autoactivation?
- is the user owning the connection logged in (if it's restricted
to a user)?
- if the profile requires secrets, is somebody previledged around
to potentially provide them?
- was the connection previously manually disconnected by the user
(which marks it as blocked from autoconnecting again)
- did a previous connection attempt fail, e.g. no DHCP lease. If
it failed $configurable times, it will be blocked for a few
minutes.
With supplicant, NM intersects the list of autoconnect candidates with
the list from the scan-list, and decides which to (auto) activate. As
far as supplicant is concerned, this is not happening automatically,
and there is no race.
If I understand you, the reason to let iwd automatically pick a
network, is because iwd knows better.
But in case there are multiple autoconnect candidates that could be
activated, then NM chooses the candidate which
- has the highest autoconnect priority (configurable)
- was used the least long ago.
Indeed, NM doesn't consider the signal strength and other Wi-Fi
properties. It's a missing feature.
How is iwd choosing automatically? Choosing based on signal strength
and encryption parameters would be a nice feature, but what about non-
Wi-Fi related factors.
How will iwd allow NM to contribute to that decision?
best,
Thomas
signature.asc
Description: This is a digitally signed message part
_______________________________________________ networkmanager-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/networkmanager-list
