Re: How to activate MAC address randomization?

2016-05-16 Thread Chris Laprise



On 05/16/2016 12:03 PM, poma wrote:

On 13.05.2016 00:16, Dan Williams wrote:

On Fri, 2016-04-29 at 16:09 -0400, Chris Laprise wrote:

Hi,

I just installed NetworkManager 1.2 in fedora 23 in the hopes that I
can
get mac randomization working. Only problem is there's no sign of a
setting for this in nmcli or the applet. I found a reference to a
setting on the NetworkManager.conf manpage which states:

 wifi.mac-address-randomization
 If left unspecified, MAC address randomization is
disabled.

wpa_supplicant only gained the necessary functionality that
NetworkManager looks for back in late October 2015.  It was committed
after wpa_supplicant 2.5 but it appears there hasn't been a release
since then.  But once that happens, or if you build supplicant version
from git, NM will begin to use that capability if you've enable it in
the NM configuration.

http://w1.fi/cgit/hostap/commit/?id=e50c50d5a090a6a52af6d92ee3a3c9cc37743747

Dan


dbus: Expose interface globals via D-Bus properties - 2.5 backport
https://bugzilla.redhat.com/show_bug.cgi?id=1336495

Professor, your patch your move ;)


LOL, that's great. I hope this means the feature could land in Fedora 
24, which has wpas 2.5.


Chris
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: How to activate MAC address randomization?

2016-05-16 Thread poma
On 13.05.2016 00:16, Dan Williams wrote:
> On Fri, 2016-04-29 at 16:09 -0400, Chris Laprise wrote:
>> Hi,
>>
>> I just installed NetworkManager 1.2 in fedora 23 in the hopes that I
>> can 
>> get mac randomization working. Only problem is there's no sign of a 
>> setting for this in nmcli or the applet. I found a reference to a 
>> setting on the NetworkManager.conf manpage which states:
>>
>> wifi.mac-address-randomization
>> If left unspecified, MAC address randomization is
>> disabled.
> 
> wpa_supplicant only gained the necessary functionality that
> NetworkManager looks for back in late October 2015.  It was committed
> after wpa_supplicant 2.5 but it appears there hasn't been a release
> since then.  But once that happens, or if you build supplicant version
> from git, NM will begin to use that capability if you've enable it in
> the NM configuration.
> 
> http://w1.fi/cgit/hostap/commit/?id=e50c50d5a090a6a52af6d92ee3a3c9cc37743747
> 
> Dan
> 

dbus: Expose interface globals via D-Bus properties - 2.5 backport
https://bugzilla.redhat.com/show_bug.cgi?id=1336495

Professor, your patch your move ;)


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


Re: [PATCH] Re: OpenConnect, Juniper and NetworkManager

2016-05-16 Thread David Woodhouse
On Sun, 2016-05-15 at 13:23 -0400, Ian Turner wrote:
> On 05/09/2016 04:02 AM, David Woodhouse wrote:
> > 
> > Thanks for looking at this. I'm still slightly concerned about exposing
> > this to users in its current form — I'd like to pass the HTML directly
> > for rendering, instead of using our half-baked parser which can only
> > handle the trivial common cases in the Juniper example forms.
>
> I agree this approach is a better way; but unfortunately it's also more
> than I'm willing to bite off. Sorry.

Understood. I'm more mentioning it to explain my reticence about
exposing Juniper mode in NetworkManager. But I think the time has come
to do it (NM support) anyway, incomplete though it is. It does work for
a lot of people already.

> > Could we drop the boolean NM_OPENCONNECT_KEY_JUNIPER_MODE and just have
> > a string key that contains exactly the string that's passed to
> > openconnect_set_protocol(), please?
>
> The problem is that while the authentication piece uses the OpenConnect
> library, NetworkManager itself kicks off openconnect via the command
> line (see the change to nm_openconnect_start_openconnect_binary). So
> unless you are prepared to change the OpenConnect command line to take a
> parameter like --vpn-type, NetworkManager will need to know some details
> about the type of VPN.

Good point. I've added a --protocol option on the command line:
http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/67ba82a

We can still special-case "nc" → "--juniper" in nm-openconnect-service
for now, to avoid *requiring* the new version. But before adding any
new protocols (i.e. Pulse) we'll add a proper way of querying which
protocols are supported, and make sure we use --protocol in future.

> > And if it's absent/empty then we do
> > nothing and hence default to AnyConnect. That makes it nice and generic
> > and easier to support other VPN protocols in future. We do have at
> > *least* Junos Pulse in the works — I have it decoded, and just need to
> > find the time and motivation to hook up all the EAP nonsense. Or
> > preferably a willing volunteer who actually *uses* it :)
>
> I can test Junos Pulse as well.

Yeah, someone just needs to write the support. Perhaps I should list it
as a GSoC project for next year...

> > 
> > Can we make this appear to NetworkManager as two *separate* plugins,
> > that just happen to use (mostly) the same binaries? The properties
> > plugin does have the name hard-coded so it can't be *entirely* the same
> > binaries... but see GNOME bug #765732 where the GTK parts are all taken
> > out into a *separately* loaded library anyway, so that can still be
> > shared while the plugin itself is built for both Juniper and
> > AnyConnect, returning different values for PROP_NAME/PROP_DESC?
>
> Yes, I'm happy to take a crack at this.

Great, Thanks!

-- 
dwmw2



smime.p7s
Description: S/MIME cryptographic signature
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list