Re: How does IWD handle setting MAC address?

[Marcel Holtmann <marcel holtmann org>]

Hi Andrew,

> > 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.

it might be fair separation of duties, but it also mean you have drawn the short straw.

Keeping wpa_supplicant as another WiFi backend is fine I think. However we need to stop to kid ourselves that 
iwd and wpa_supplicant are the same or ever will be the same. The only thing they have in common is that they 
deal with WiFi to a certain degree.

Frankly, a system using NM + iwd does not have to offer the same options has a system using NM + 
wpa_supplicant. A lot of people will most likely never notice is some esoteric WiFi options are missing. So I 
would actually start treating them different and slim the UI to just not show options that a combination of 
iwd + NM can not support (or just does automatically without requiring user interaction).

Of course this means that NM needs to change a bit in its plugin abstractions for WiFi. Then again, so be it. 
I believe that a system with NM + iwd will lead a way better and more stable user experience.

> 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.

Actually it doesn’t. If you want to have this kind of keep me on the best network, then you need profiling of 
the network quality. That is something we just don’t have at all right now. However at the end of the day 
this is just switching the default route (or application based route) depending on some quality measurement. 
It really doesn’t mean that WiFi or LTE gets disconnected. They both stay active and NM decides which one get 
the appropriate routing information.

This also means that if you get your LTE connection found as the best connection, iwd will still roam and do 
its job in the background connection to know networks. Once iwd provides a better quality connection, NM can 
switch. The question is if such measurement can be done based on netdev or if individual technology daemon 
like oFono and iwd have to provide it, that is a different question.

> 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.

I think NM has to give up its WiFi auto-connect logic. It can store auto-connect=on/off for a iwd known 
network, but that is it. And yes, all the known networks and its properties / settings need to be pulled over 
D-Bus from iwd.

Regards

Marcel