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