Hi Andrew, On Sat, 2018-01-06 at 01:23 +0100, Andrew Zaborowski wrote:
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.
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. 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 don't like this idea for its complexity but I'm not sure if there's a better way.
That's a good question :) best, Thomas
Attachment:
signature.asc
Description: This is a digitally signed message part