On Wed, 2017-12-06 at 00:41 +0100, Andrew Zaborowski wrote: > Hi Dan, > > On 5 December 2017 at 17:47, Dan Williams <[email protected]> wrote: > > On Tue, 2017-12-05 at 16:26 +0100, Andrew Zaborowski wrote: > > > Let the config file select between creating classes of > > > NMDeviceWifi > > > (for the usual wpa_supplicant based devices) and NMDeviceIwd > > > depending > > > on the new NetworkManager.conf setting. > > > > This seems wrong to me. We usually try to keep things runtime > > enabled > > rather than add config options like this. Is there any reason you > > would have both wpa_supplicant and iwd running on the same system > > at > > the same time? > > No, you'd want to avoid that for wifi devices. That's why I think > even separate (conflicting) plugins would be fine in this case but > I'm > not sure if this is possible with NM's current plugin system.
Conflicting plugins would be a possibility, but as the name NetworkManager-wifi is already taken, there is no good name left. Also, I think there is an advantage of having one plugin support both backends. It makes it much easier for distributions to support both supplicant and iwd. But I also think that the backend cannot be detected reliably. So, a configuration option seems necessary to force a backend (possibly to overrule autodetection). Maybe the documentation should not say: <literal>wpa_supplicant</literal> is also the default backend. but instead: "if the setting is missing, it is autodetected.". -- although for now, it means to always ~detect~ supplicant. Would it ever make sense that one device is managed by supplicant and another by iwd? I think it would. Maybe this should hence be configured via [device] wifi.backend=<wpa_supplicant|iwd> the [device] section allows to configure settings per-device, like /etc/NetworkManager/conf.d/10-wifi-backend.conf: [device-wifi-backend-wlan0] match-device=interface-name:wlan0 wifi.backend=iwd [device-wifi-backend-default] wifi.backend=wpa_supplicant We currently lookup such configuration via nm_config_data_get_device_config(). But inside the device-factory you don't have a NMDevice instance at hand, to make that decision. We would need a new "nm_config_data_get_device_config_by_ifindex()", to get the matching parameters from NMPlatform. We can do this later -- but before 1.12.0 release. > > Could we check whether the iwd dbus service is claimed > > and just use iwd if it's running? > > We could do that but it'd rely on iwd running before NetworkManager > starts, maybe that's not an issue. I seem to remember a DBus design > guideline according to which clients should tolerate services coming > up and going away. > > Best regards > _______________________________________________ > networkmanager-list mailing list > [email protected] > https://mail.gnome.org/mailman/listinfo/networkmanager-list
signature.asc
Description: This is a digitally signed message part
_______________________________________________ networkmanager-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/networkmanager-list
