GNOME.org
 

Re: How does IWD handle setting MAC address?

On Fri, 2018-01-05 at 14:58 +0100, Thomas Haller wrote:

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?


Note that choosing based solely on signal strength can be problematic. 
It works great if you are somewhere that has only one AP you've
connected to before.  But the moment you have multiple different SSIDs
that you've connected to before, it starts to have issues.

An example case was the old Red Hat (or was it Mozilla, I forget, they
were right down the street from each other) office in Mountain View,
which was just upstairs from a Starbucks.  Depending on where you were
in the office, Starbuck's APs could be stronger than the office ones. 
These days even "public" APs have strong encryption with automatic
login (HotSpot 2.0, EAP-SIM, etc) too.

---

Looking at the iwd code, it appears to:

1) only autoconnect to networks that have been successful at least once
(see comment in network.c::network_rankmod())

2) BSSs are ranked according to factors in
scan.c::scan_bss_compute_rank() which is heavily biased towards signal
strength.  After that, better encryption, 5G, and low utilization (read
from an IE) is preferred.

3) then the BSS is added to its network object; network objects are
tracked in a list and the most recently connected networks since IWD
has been running are first; the rest are in reverse-order-seen (see
network_info_get()).

4) when generating the autoconnect list, the BSS's rank from #2 is
multiplied by a "rankmod" number (<=1) that depends on where the BSS's
network is in the list from #3 (device.c::process_bss()).  So BSSs that
were previously connected to have a lower rank, and BSSs that haven't
been connected to yet this IWD run could be even lower.

However, since the BSSs have ranks themselves, this modifier appears to
allow situations where IWD would switch from SSID A to SSID B, even if
A was still visible, when there is a much-stronger SSID B AP.  I could
be wrong of course.  But this would break expectations around how NM
currently works, where it holds on to the current SSID until the
connection is broken.

Perhaps this is desirable, maybe it allows the dual-channel AP
situation where for example you are on 5GHz SSID A and move to another
room, so A becomes low signal, but the 2.4GHz SSID B is now much
stronger so IWD reconnects to that one.  However, this could result in
an IP address change depending on how your AP works, which would break
existing connections.  Which is one reason NM doesn't normally switch
between SSIDs.

I'm sure Marcel will correct anything I've gotten wrong above.

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