Re: How does IWD handle setting MAC address?

Hi Thomas,

I am in favor of address randomization even while it has
affect, but at least for background scanning it is useful.
doing this via RTNL is causing a weird layer violation and
of potential races and issues. This needs to be done with
awareness of cfg80211 and thus via nl80211. So iwd should
iwd should just expose an on/off switch for WiFi Privacy.

TL;DR: the policy of which MAC address to use (and when) is
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
important which bits of the address to scramble (and choose a
known manufacturer OUI)[1].
I personally don't agree with the importance of such
but I'd like NetworkManager to be the first choice for people
particular need -- regardless of whether this need is real or
In NM you can configure how the bits are scrambled very
while scanning[2] and while being associated[3].

More interesting is, I don't only want to have a random MAC
while scanning, but also while being associated. My permanent
address should never ever be reveiled.
But a new random MAC address on each new association isn't
what you
want either, because then I get a new IP address from DHCP
time and have
to redo captive portal login.
So, I want for each of my Wi-Fi profiles a different, stable
address. Actually, for public networks like a hotel, I want
stable MAC address for a limited amount of time. The example
show how to do that in NM.

I have nothing against an option that says generate a new MAC
for this SSID and keep using it from that time forward.

If I understand correctly, you agree that the MAC address depends
the profile.

It is a bit counterproductive if nl80211 doesn’t allow to
MAC address for association. Since powering down WiFi, changing
address and powering back up is something that I am strictly

So if these things are what people really want, then neither NM
iwd should actually do the heavy lifting for it. It should be
the wireless stack in the kernel.

Ok, whatever works best.

That said iwd should cope Ok with the MAC address changing
back if it receives the RTNL notification (RTM_NEWLINK) if
connected.  It always updates it's copy of the address on a
RTM_NEWLINK so the race condition shouldn't be present I

I would think so too. NM change the MAC address via RTNL only
scanning, early during activation, and late during
As the wireless daemon does/should not autoactivate the
NM's wish and NM determines that the device is deactivated
an event from iwd.
Hence, there shouldn't be a race of NM interfering while
connected. The race is only while scanning and iwd should
with that.

Alternatively/additionally, a SetMacAddress() D-Bus call
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
decision making for connecting to known WiFi networks. It just
as dumb as wpa_supplicant and from a NM perspective, you should
doing as little as you do with BlueZ or oFono.

This means iwd needs to be told what to do and not just an
It doesn’t matter if it is via a D-Bus call or RTNL. iwd
known networks and will connect to them if they are in range,
automatically and also switch networks if it makes sense. That
any randomization policy would have to be executed inside iwd
outside. As stated above, if you want different MAC addresses
SSID, then that needs to be inside iwd.

So many things in the wpa_supplicant design led to “hacks”
add features and that really has to stop. It is not
the corner cases and race condition this architecture causes is

For NM, at each moment not all its connection profiles are
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
  to a user)?
- if the profile requires secrets, is somebody previledged
  to potentially provide them?
- was the connection previously manually disconnected by the
  (which marks it as blocked from autoconnecting again)
- did a previous connection attempt fail, e.g. no DHCP lease.
  it failed $configurable times, it will be blocked for a few 

With supplicant, NM intersects the list of autoconnect candidates
the list from the scan-list, and decides which to (auto)
activate. As
far as supplicant is concerned, this is not happening
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
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
and encryption parameters would be a nice feature, but what about
Wi-Fi related factors.
How will iwd allow NM to contribute to that decision?

Note that choosing based solely on signal strength can be
It works great if you are somewhere that has only one AP you've
connected to before.  But the moment you have multiple different
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,
were right down the street from each other) office in Mountain
which was just upstairs from a Starbucks.  Depending on where you
in the office, Starbuck's APs could be stronger than the office
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
(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
strength.  After that, better encryption, 5G, and low utilization
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
has been running are first; the rest are in reverse-order-seen (see

4) when generating the autoconnect list, the BSS's rank from #2 is
multiplied by a "rankmod" number (<=1) that depends on where the
network is in the list from #3 (device.c::process_bss()).  So BSSs
were previously connected to have a lower rank, and BSSs that
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
A was still visible, when there is a much-stronger SSID B AP.  I
be wrong of course.  But this would break expectations around how
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
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
an IP address change depending on how your AP works, which would
existing connections.  Which is one reason NM doesn't normally
between SSIDs.

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

a lot of these can be changed or fine-tuned while we are making iwd
better. However the big point is that iwd knowns about the known
networks and stores them. So we need to work with basic premise of
this. Same as BlueZ knowns its PAN devices and oFono knows its SIM
cards and APNs. That really has to be the assumption first and

That BlueZ remembers PAN devices makes sense, because these devices
were paired outside of NetworkManager, using bluetooth tools.

BlueZ/oFono autonoumously connects? I didn't think that is the case, it
it? AFAIS, it's always NetworkManager which initiates the activation.

actually with iwd you can also use iwd tools to connect your WiFi, you do not need to go through NM. And we 
need to support that kind of interaction as well.

As I said before, I full realize that wpa_supplicant made you do everything, but with iwd that is no longer 
needed. For example you can have a dead simple UI element that just trigger WPS based connection. You do that 
via iwd and then move on with life. NM will pick up the new known network and its connection. Everybody will 
be happy.

iwd is different than wpa_supplicant and it is a change for the better :)

And yes, I know wpa_supplicant dealt everybody a bad hand and told
you to deal with it. However we need to change this mantra towards
something clean and modern. Especially since there are so many WiFi
extensions that will allow you to make decision that wpa_supplicant
will never give you access to. So lets figure out what is needed and
tune around that.

For the IP address part, I will assume that iwd will actually start
doing DHCP itself soon. That is just needed if you look at some of
the features that tell you about IP address during association or the
brain-dead things like P2P. We are toying with this, but I almost
certain this will go in this direction. Similar on how cellular
modems actually do it. The IP address is a property of the WiFi
daemon and not the daemon that manages the network connections.

With WWan/ModemManager, pppoe/pppd, VPNs, the IP addressing is also
negotiated outside of NM.
Also, supplicant supports DHCP
( )
-- although NM doesn't support that. It's a missing Wi-Fi feature, but
I don't see a fundamental issue with NM+supplicant+FILS).

But while these components negotiate IP addresses one way or another,
they only report the address/routes to NM, and NM might them.

Would iwd actively configure addresses/routes? If not, that is fine
not different from e.g. WWAN.

Routes is a clear no. That is never part of the interface itself. For the IP address that is something we 
need to discuss. So far we have stayed away assigning IP addresses in the technology daemon and just told the 
managing entity above what these were or to run DHCP.

So we think that DHCP needs to be in iwd (and for P2P that means client+server). We also arrived at the 
conclusion that BlueZ and oFono should do DHCP by themselves if no static IP addresses can be read. For DHCP 
to function nicely and efficiently however it is important that the IP address also gets configured on the 
interface. So I think that eventually we need to move towards that technology daemon controls the interface 
and its addresses.

This needs a bit more thinking and research on who configures the IP, but the DHCP part is clearly moving 
into iwd.

I think iwd configuring addresses is wrong. Because this affects
routing, which very much determines the system-wide behavior and needs
to interplay with the interfaces.
For example, in NetworkManager you can:
 - Configure ipv4.route-metric. For example, if you connect to your
   home network both via cable and Wi-Fi, (configurably) cable will 
   be preferred.
   Or if you activate WWAN and Wi-Fi at the same time, the default-
   route gets a metric based on the device priority (configurably).
   (in some cases, the route-metric might even be determined the 
   moment when starting associating. In combination with iwd 
   autonomously connecting, you couldn't even configure the desired 
   route-metric in the iwd profile).

The route metric is clearly part of NM. That should not be in control of a technology daemon.

 - configure ipv4.never-default: controls whether the interface will 
   get the default route.

See no problem here. Since iwd would never touch any routes.

 - configure additional manual routes for that  interface. If iwd and
   NM both configure routes, this is racy.

No interest in routes.

 - Configure ipv4.route-table. An uncommon feature, where you can 
   put the routes from that interface in a separate routing table for 
   policy routing.

Same as above, no interest in routes.

 - protect routes on other interfaces so that a malicious DHCP server 
   cannot hijack traffic
   ( ). While this is
   not implemented yet and hard to get right conceptually, it would
   be a great feature.

See also no conflict there.

As I said, the routes and all its details is really not iwd business. So we are clear and agree on that. The 
IP address itself and its configuration is something where my current thinking is that this is owned by the 
technology daemon. And yes, I realize the issue with IP conflicts and overlaps. This needs a bit more 
thinking and looking into what RTNL actually provides and lets you control.

When it comes to signal strength and cases that you get bumped off
the SSID, then that is what can happen. It is especially sad if the
AP will not use neighbor cell reporting to allow you to jump onto the
next AP. But that is life and it really all depends on the speed of
DHCP to get you back onto your network, but that feeds into my
comment above where DHCP has to become part of the WiFi daemon.

The other part is that iwd really has all the information to know
your network. It knows when it saw them last, connected last and
eventually even what your surrounding SSIDs were. For example even
you can not connect to your home neighbors encrypted WiFi, the pure
existent of it around you, means you might want to connect to your
home SSID and preferably _quickly_ (last known channel) for it and
connect. This is knowledge and use of this knowledge that really only
works with iwd and fiddling any of this through wpa_supplicant is
crazy. And some hardware has actually offload capabilities for
background scanning around the concept of neighboring SSIDs.

I don't understand how this takes into account other factors that that
seem very important to me.

If NM disconnects from one BSSID, it might want to re-connect to the
same or another. It's unclear how iwd would be able to handle the
difference, if it doesn't allow to specify which BSSID to connect to.

Why would you care to get re-connect to the same BSSID. Why should NM make that call if it doesn’t have 
access to surrounding BSSIDs or neighboring BSSID information or band steering information. If the AP wants 
you to move from 2.4GHz to 5GHz, re-connect to the previous BSSID is 100% the wrong thing to do.

Please keep in mind that iwd is far away from having all the features
we envisioned. It is getting there and NM really needs to move
towards trusting iwd. It is the only way we can improve the WiFi
experience in desktop Linux.

It's not about trusting. It's about how NM can use iwd's API to
implement use-cases that are useful. Maybe not useful in the car, but
on a notebook.

Maybe iwd is not providing the hackers dream of configurations, but it will provide useful features. And I am 
totally fine with someone saying they want some crazy configuration knob. However that might also mean they 
have to stay with wpa_supplicant as backend. But staying with wpa_supplicant will clearly mean that you not 
profit from some of the advanced 802.11 features we are adding into iwd and where we are also working on 
enabling nl80211 features for it.

But I still strongly believe that NM + iwd will give 99% of the users a better WiFi experience.

On a side note here, some of the AP manufactures have a hard time with not supporting advanced 802.11 
features for roaming, neighboring cells or band-steering. This becomes even more important with mesh systems 
and multi-AP systems in the future. I really don’t see how NM can take advantage of many things while 
sticking with wpa_supplicant. I think NM has to give up some control to iwd to improve user experience.



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