On Thu, 2016-01-28 at 17:58 +0100, Toby wrote: > 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.
The supplicant does have a ton of options (some useful and some not), but punching a hole through isn't a great solution the problem at hand and doesn't lend itself to a great user experience, whether that's a GUI or a CLI. Instead, if you think you need to customize some option, we'd love to hear about it so we can figure out if there is a way to achieve your goal using that option, or some other way. As I said before, I don't think this warrants a new NMSetting property, but clearly there is need for a different workaround for the TLS v1.2 case. Dan > 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
