I fully understand that this specific TLS1.2 issue is temporary and doesn't need to be addressed specifically. But there are many more wpa_supplicant parameters not covered by the settings spec, and there might be even more in upcoming releases. NM will always lag behind to some extend. Therefore, I'd vote for a custom settings field, which allows to specify a list of key/value pairs as a single string (based on a certain syntax), and which get's passed thru to wpa_supplicant as a sequence of parameter/value combos blindly. This would be a flexible way to address any potential future issues directly. Of course, there's no need to expose such a setting to GUIs.
I had been hoping for such a feature to exist without being documented (as it would be one of the first things I'd implement), but it looks like this is not the case. Toby Am 28.01.2016 17:25 schrieb "Dan Williams" <[email protected]>: > On Thu, 2016-01-28 at 09:50 +0100, Toby wrote: > > Hi, > > due to a delay in the upgrade of our corporate radius servers, I > > temporarily need to deactivate TLSv1.2 in phase1 of WPA2/EAP-PEAP, to > > bypass a conflict with wpa_supplicant >=2.4. (known issue) > > In wpa_supplicant.conf this would require a parameter > > phase="tls_disable_tlsv1_2=0". > > But this parameter is not covered by the current settings spec, > > correct? > > How to deal with this situation? > > Is there a way to extend a profile with arbitrary wpa_supplicant > > parameters? > > Or can I merge stuff from wpa_supplicant.conf with settings > > transferred via > > DBUS? > > Or is excluding this WiFi network from being managed by NM the only > > valid > > solution? > > Currently, exclusion or downgrading the supplicant to a version that > does not advertise TLS v1.2 support (eg, downgrade to <= 2.3) are the > solutions. I don't think we want to add a setting property for this > since it will eventually no longer be required, but perhaps a config > file parameter or some other out-of-band mechanism to disable TLS v1.2 > where needed would be acceptable, and that can be dropped at a future > date when this is no longer a problem. > > Dan >
_______________________________________________ networkmanager-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/networkmanager-list
