Hi Dan, On Thu, Jan 28, 2016 at 12:21:24PM -0600, Dan Williams wrote:
> 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. A bit of feedback from an enduser, if I may: I've also found myself in the same situation as Toby, but not with some wpa_supplicant option but with an openconnect option. I don't remember the details but as it was I could not establish an OpenConnect VPN connection using NetworkManager, so I had to invoke the openconnect binary directly, with sudo and everything. At that time I thought "it'd be nice if NetworkManager allowed me to plug in extra command arguments for openconnect in NetworkManager.conf". I think at some other time I needed to debug a DHCP problem and needed to pass special arguments to dhclient. One can create wrappers, of course, but I personally prefer tweaking configuration files because then my changes are respected and preserved by the package manager. So, I do think there is value in providing a way to pass extra arguments to the binaries that NetworkManager invokes. It should not be something that is exposed to users via user interfaces but NetworkManager cannot possibly get 100% right all the time all the options that the binaries that it spawns support and that could be helped by providing a way to add arbitrary arguments. Anyway, I do love NetworkManager, and thank all of you for all the work you put into it. Cheers, Eloy Paris.- > > 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
