GNOME.org
 

Re: How does IWD handle setting MAC address?

Hi Thomas,


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.


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


can we not just have some sort of supported configuration features. Meaning the wpa_supplicant plugin will 
allow you to have 20 different knobs and the iwd plugin might be limited to 5 (just making up numbers here).


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

But:

- NM profiles contain more information (e.g. proxy setting, firewall 
  zone), either the profile backed by iwd is lacking, or a lot of 
  work.
- 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 think that you have to keep your NM profiles. That is your basic concept. However I think it needs to gain 
the functionality that certain properties of profile are “virtual” and provided by an external entity, in 
this case iwd.

If you see a new known network in iwd, you need to create a new profile with default values within NM. And 
just store the extra values like proxy setting etc. Same goes for the removing case. Keeping profiles for 
networks removed from iwd around is fine as well. As long they get marked inactive or abandoned and only get 
resurrected when iwd re-adds that network.

So can we have some way of syncing NM profiles with iwd known networks, but have the iwd list as the source 
of active / valid NM WiFi profiles. And then have certain properties be controlled by iwd. In theory you can 
store a copy in the NM profile, but the true value should be in iwd.

For example, if someone uses the iwd D-Bus API to change the auto-connect property, I would expect NM to pick 
up that change and honor. No backstabbing and overwriting something. If it is configured via NM D-Bus API it 
must be seen as valid as if it would be configured via iwd D-Bus API.

If we can make that work, I think this should be not a problem to integrate nicely.

And yes, I realize that NM treated wpa_supplicant as being its single and only user. That is not a concept 
iwd provides anymore. I think that is another big re-thinking for everybody. It is the same as with oFono and 
BlueZ, the connection managing daemon has to deal with changes done directly via its technology daemons.

Regards

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