Re: How does IWD handle setting MAC address?

Hi Andrew,

On Sat, 2018-01-06 at 01:23 +0100, Andrew Zaborowski wrote:

On 5 January 2018 at 14:58, Thomas Haller <thaller redhat com> wrote:
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 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

With supplicant, NM intersects the list of autoconnect candidates
the list from the scan-list, and decides which to (auto) activate.
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 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
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?

I have been thinking about actual ways this could be implemnted
because I talked to Denis about this as a long term goal for the
iwd-NM integration.  It would clearly require a major rework and
keeping wpa_supplicant as the other backend would be difficult too.
This stems from the fact that currently NM is the wifi daemon in the
sense that Marcel talks about.  All wpa_supplicant does is keep a
specific connection alive (including roaming if needed) and that is a
fair separation of duties.

I believe there are situations where the current approach with NM
managing all of the profiles at the same level has an advantage, for
example it allows roaming between wifi and 4G depending on the best
throughput -- not only based on the presence of wifi networks.  My
current android phone has this option in advanced wifi settings.

I agree.

One way to keep the current NM user API mostly intact would be to
special-case wifi profiles and prevent NM from ever storing them.
They'd have to be pulled from iwd over DBus when the UI asks for
This would touch much more code in NM than just the src/devces/wifi/
and could be ugly.  NM would have to tell iwd the minimum parameters
it is expecting from a wifi connection based on what other connection
methods are available.  If iwd can locate an AP that is good enough
is free to use its own autoconnect logic, otherwise it would have to
give it up for NM to use another radio access technology.

I think it would be ugly if NM has two connection types: wifi-
supplicant and wifi-iwd. Because it would also require to implement
different types in the GUIs. Which is confusing to the user, but worst,
it moves the effort to handle with two backends higher up to the user,
instead of one place in the wifi plugin.

Also, NM supports settings plugins, so in theory you could store the NM
connection as iwd profile.


 - NM profiles contain more information (e.g. proxy setting, firewall 
   zone), either the profile backed by iwd is lacking, or a lot of 
 - in general, setting plugins are a lot of work. That is why we only
   really have "ifcfg-rh" (all other are very limited, to the point
   of not being useful).

I don't like this idea for its complexity but I'm not sure if there's
a better way.

That's a good question :)


Attachment: signature.asc
Description: This is a digitally signed message part

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