Re: How does IWD handle setting MAC address?

[Andrew Zaborowski <andrew zaborowski intel com>]

Hi,

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

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.

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 them.
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 it
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 don't like this idea for its complexity but I'm not sure if there's
a better way.

Best regards