Re: How to deal with unsupported wpa_supplicant parameters?

[Eloy Paris <peloy chapus net>]

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" <dcbw redhat com>:
> >
> > > 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