GNOME.org
 

Re: How does IWD handle setting MAC address?

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.


yes, I am totally fine adding such an option to iwd. Just to be clear, when you say profile, you mean “same 
SSID with matching security”. So either Open, Personal (WPA/RSN) or Enterprise. Essentially a roaming group. 
The BSSID is never really in control of the caller, but could be give out as debug info if really needed.

Scanning with a random address and generating an address for a given SSID group is a total acceptable feature 
to be added. But I really have to stress that I want this done in iwd and not behind its back.

However generating a new random address on each association is a total crazy feature. It actually breaks the 
roaming case and is not something I would be supportive of. Same goes for letting the user specify one is 
such a corner case. If you are a WiFi black hat and want to do some spoofing, then please do that, but don’t 
expect us to enable this. That is like < 1% users.

In summary, privacy additions that benefit every user is totally fine by me, but hacker enabling is not on 
the todo list.


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.


Maybe Andrew can have a look at what it takes to specify the MAC address on nl80211 connect or 
authenticate/associate. That really is essentially the right thing to do since then we can track this 
properly. Keep in mind that this would be really needed when you want to run station mode and P2P at the same 
time. And we really can not power down the wiphy and break a P2P link to just use another MAC address for the 
next association.


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.


Yes, pretty much. And it will be also faster and it needs that to do a more efficient scanning. For each 
known network (to use the iwd term for a SSID group), we could add a property to specific auto-connect or 
not. That property would have to be toggled by NM from its profile view. Essentially NM will not store these 
things locally, but instead treat iwd as its storage backend for WiFi.


But in case there are multiple autoconnect candidates that could be
activated, then NM chooses the candidate that
 - has the highest autoconnect priority (configurable)


I am not a big believer in the user configures the auto-connect priority. We could certainly add something 
for that to iwd, but it will not work as you might expect. I know that even macOS still offers to some degree 
this functionality, but it doesn’t. See on paper this looks great, but in reality scanning is not reliable. 
On each scan you might see a higher priority network or not (even if both are in range). So even with this 
configured, you can still get into the unlucky position that a public AP with higher output power gets 
selected because your local one is not seen in the first scan. And for obvious reasons we do not want to scan 
multiple times to just make a priority list a bit more reliable.


 - that was used the least long ago.


This is normally a better option than the priority. Sort the list of networks from the scan result by 
matching them up to last time connected.

If you think about this a bit longer and with more context (aka surrounding unknown BSSIDs), then you can get 
a better user experience by just doing the right thing. So lets assume we start storing not just the SSID, 
but also its BSSID and up to n surrounding BSSIDs. Next time around we can not just match the last connected, 
but also last connected while BSSIDs where around. And we can also optimize the scan to quick scan the last 
known channel for that BSSID with surrounding BSSIDs.

This has as most heuristics a margin for false-positives, but in the overall user experience this will 
actually self-learn the user preference. Think about it, iwd connects you wrong once, you correct it be 
manually selecting that network, next time it will look for the correct SSID based on the surrounding BSSIDs.

Some of these are to be worked on features and not a reality right now. However we have looked at this and 
buying into iwd, is buying into wanting these improvements under the hood that are visible to the user. 
Frankly you do not want to have NM deal with 5 different versions of wpa_supplicant and other funky nl80211 
or RTNL behaviors. You want that done all inside iwd and stay away from WiFi as much as possible.

All the crazy stuff we had to deal with when ConnMan uses wpa_supplicant is nasty. It is just totally 
unworkable. And I totally get that this was the “wifi daemon” you got and you had to make the best out of it, 
but I think it is really time to rethink things and move tasks and responsibilities down into the technology 
daemon where they belong.


Indeed, NM doesn't consider the signal strength and other Wi-Fi
properties. It's a missing feature.


Actually I do not care much about the signal strength. A history of neighboring BSSIDs and maybe some super 
measurement how stable a previous association was is better then even looking at the signal strength. The 
signal strength is fun to watch for the user, but it is not really help. The pathloss is a bit more helpful, 
but for that you need RSSI and output power information. So it gets all funny and some random blob of water 
(aka human) and destroy every good signal anyway.


How is iwd choosing automatically? Is iwd also allow to configure
priorities? Will it also remember to which profile it was connected
last?
Picking based on signal strength, is a nice feature, but seems not as
important as when the profile was used last.


We remember last used and last seen as of now. Surrounding BSSIDs based on the associated BSSID is something 
we have to work out, but my working assumption is that this will be best in class and we can just ignore 
priorities.

And property for auto-connect=on/off for a given known network is something that we should add.

Regards

Marcel
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]