Re: How to deal with unsupported wpa_supplicant parameters?

[Dan Williams <dcbw redhat com>]

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