Re: How to deal with unsupported wpa_supplicant parameters?

[Dan Williams]

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
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

How to deal with unsupported wpa_supplicant parameters?

[Toby]

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?

Regards,
Toby
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: [PATCH] simplify blob handling

[Thomas Haller]

On Tue, 2016-01-26 at 22:57 +0100, Matthias Berndt wrote:
> Hi,
> 
> here's the patch to simplify blob handling.


merged: https://git.gnome.org/browse/network-manager-openvpn/commit/?id
=4a94aa814f26bad03e1277b1d0d978deadb129ae


Thank you!
Thomas

signature.asc
Description: This is a digitally signed message part
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: How to deal with unsupported wpa_supplicant parameters?

[Dan Williams]

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" :
> 
> > 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
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: How to deal with unsupported wpa_supplicant parameters?

[Toby]

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
Am 28.01.2016 17:25 schrieb "Dan Williams" :

> 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
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list