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 _______________________________________________ networkmanager-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/networkmanager-list
