Re: Beyond MAC randomization (prevent tracking)

[Chris Laprise]

On 04/10/2017 01:35 PM, Chris Laprise wrote:


1. A Study of MAC Address Randomization in Mobile Devices and
When it Fails
https://arxiv.org/pdf/1703.02874v1.pdf




A listing of best practices from the paper:


Randomize across the entire address, providing
2^46 bits of randomization.

Use a random address for every probe request
frame.

Remove sequence numbers from probe requests.

If sequence numbers are used, reset sequence
number when transmitting authentication and
association frames.

Never send probe requests using a global MAC
address.

Enforce a policy requiring a minimal and stan-
dard set of vendor IEs. Move any lost function-
ality to the authentication/association process,
or upon network establishment utilize discovery
protocols.

Specifically, the use of WPS attributes should
be removed except when performing P2P opera-
tions. Prohibit unique vendor tags such as those
introduced by Apple iOS 10.

Eliminate the use of directed probe requests for
cellular offloading.

Mandate that chipset firmware remove behavior
where RTS frames received while in State 1 elicit
a CTS response.



Seems like NM and careful configuration might address some of these 
points...



(BTW, the usna.edu address appears to be disabled.)

--

Chris Laprise, tas...@openmailbox.org
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Beyond MAC randomization (prevent tracking)

[Chris Laprise]

Hello again...

Having read the recent paper on Wifi tracking by Jeremy Martin, et 
al[1], I am concerned this tracking problem based on non-MAC address 
metadata may be present for laptop systems as well. The issues involve 
WPS unique identifier fields and request sequence numbers.


There is also an example of one Android vendor who apparently 'did it 
right'.


So my question is: What can software like Network Manager do beyond MAC 
address randomization (which appears to be rendered ineffective 
according to the paper) to improve Wifi NIC anonymity?


I would like to hear the thoughts on this important subject from NM 
developers...




1. A Study of MAC Address Randomization in Mobile Devices and
When it Fails
https://arxiv.org/pdf/1703.02874v1.pdf

--

Chris Laprise, tas...@openmailbox.org
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Best practice for managing default routes over only VPN connections?

[Chris Laprise]

On 11/07/2016 01:49 PM, Stuart D. Gathman wrote:

Cool!  I had not had time to find out exactly what qubes did, but you
explained it very well.  I suspect that's not *all* qubes does, but
I'll be installing a prepackaged VM router (or hacking my own). What a 
great

concept.



Yeah, Qubes really is cool... All mundane app functions and external 
connections are done in virtual machines which are controlled with very 
simple/safe interfaces by the bare-metal hypervisor, Xen. It does the 
same for hardware, too... Network and USB controllers especially are 
confined to service VMs using the IOMMU to ensure DMA-based attacks 
don't yield access to the rest of the system.


OTOH, the admin VM has no network access. Its job is to run the GUI and 
local storage, and manage the unprivileged VMs (which by default run 
from read-only OS templates). The Qubes graphics stack prevents the 
usual GUI vulnerabilities with VM running on Linux, e.g. no clipboard 
sniffing or bitmap spying; it also displays window borders with VM name 
and assigned color so there's little or nothing a compromised VM can do 
to fool you.


The overall idea is to stuff most of the complexity and attack surface 
of a modern desktop into isolated, unprivileged VMs. You have to trust 
only a much smaller admin VM, tiny Xen hypervisor and core hardware 
components. From there, its up to the user to organize their activities 
and data into different VMs like "personal", "work", "untrusted".


BTW, some Qubes users are experimenting with router and network VMs that 
utilize microkernels. However, the default OS templates (Debian and 
Fedora) make pretty good routers themselves.


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

Re: Best practice for managing default routes over only VPN connections?

[Chris Laprise]

On 11/07/2016 06:57 AM, Thomas Haller wrote:


Another thing is ensuring that all traffic is routed via the VPN (that
is, controlling the configured routes). That is not supported by NM
directly (besize that you can manually configure your underlying
connection to have no default-route and only give a default-route to
the VPN connection). See for example
https://bugzilla.gnome.org/show_bug.cgi?id=749376 .



FWIW... If the OP is inquiring about a 'fail closed' configuration that 
can prevent any traffic leaking from the tunnel, then he may want to 
look at Qubes OS where users can define a 'Proxy VM' to control all 
traffic in this way. This means the VPN is running inside a forwarding 
*router* and preventing leaks becomes a much simpler matter of stopping 
any forwarding to clearnet NICs.


https://theinvisiblethings.blogspot.com/2011/09/playing-with-qubes-networking-for-fun.html

https://www.qubes-os.org/doc/vpn/

You can get the same effect with a dedicated physical router, but then 
you'd have to carry that around (and router devices get exploited a lot 
these days).


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

Re: Best practice for managing default routes over only VPN connections?

[Chris Laprise]

On 11/06/2016 07:30 PM, Paul Swanson wrote:

Hello,

I've recently been configuring my Ubuntu 16.10 laptop for default 
routing via VPN only and have discovered some difficulties.


My goal is to only connect to the Internet via a VPN and ensure that 
DNS requests are resolved by a trusted server only.


One thing I've noticed is that DNS resolution seems to be handled by 
NM on a connection by connection basis, but I want to ensure that DNS 
resolvers are fixed to my choice regardless of the underlying 
connection, without giving up NM control and dnsmasq for caching.


From what I've seen so far, the configuration bias is towards VPN 
connections providing tangential access to a private network and NOT 
as the default route.


I do recall seeing at least one howto for tunneling all traffic over SSH 
a long time ago. However, SSH may not be necessary Some VPN services 
offer OpenVPN access on port 443 (HTTPS) for example; This should work 
at least as well as SSH.



Chris



Would genuinely appreciate any guidance on how to best proceed here.

Thanks,

Paul S.

Sent from ProtonMail , encrypted email based 
in Switzerland.





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


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

Re: Troubleshooting NM 1.4.0 (was 'How to activate...randomization?')

[Chris Laprise]

On 10/14/2016 12:43 PM, Thomas Haller wrote:

On Fri, 2016-10-14 at 11:00 -0400, Chris Laprise wrote:

On 08/31/2016 01:16 PM, Thomas Haller wrote:

On Wed, 2016-08-31 at 12:07 -0400, Chris Laprise wrote:

I am trying out the new NM in Debian testing by installing the
network-manager 1.4.0-3 and network-manager-gnome 1.4.0-2
versions
from
unstable.


NM 1.4 shows up in the systray, but won't display any access
points.
It
does seem to be trying to manage the wifi device, as its MAC
address
now
changes to a random number; I can see this with ifconfig.


NM 1.2.4 had been working fine before the upgrade.


Any troubleshooting suggestions

Hi,


could be https://bugzilla.gnome.org/show_bug.cgi?id=770456
or https://bugzilla.gnome.org/show_bug.cgi?id=770504

please send the logfile with level=TRACE. Thanks

Thomas

Hi Thomas,

The patches appear to be working, as the new 1.4.2-1 release that
landed
in Debian testing is able to randomize both scanning and connections
now.

However, it doesn't adhere to what is shown on the nm-settings man
page.
The assigned-mac-address setting is described as superceding the
deprecated cloned-mac-address. But NM will only randomize during
connections if cloned-mac-address is used.

wifi.assigned-mac-address=random

...has no effect, but

wifi.cloned-mac-address=random

Hi Chris,


Thanks for reporting back.


There are three manual pages

   (1) nm-settings
   (2) nm-settings-keyfile
   (3) nm-settings-ifcfg-rh

Mostly they are similar, but
   (1) describes the properties on the D-Bus API
   (2) the properties in keyfile format
   (3) the properties in ifcfg-rh format

what does not exist, is

   (4) nm-settings-nmcli (how are the properties call in nmcli)

the property wifi.assigned-mac-address exists only on the D-Bus API
(1). It was added there, because the existing wifi.cloned-mac-address
property could not be extended to support the new options.

On all other occasions, there exists only wifi.cloned-mac-address.
That's what it's called in nmcli and NetworkManager.conf.

Note that nmcli and `man NetworkManager.conf` does not mention
wifi.assigned-mac-address.

That is all expected.

ciao,
Thomas


One additional issue...

When I upgrade my network VM from NM 1.2 to 1.4, something about the old 
connection settings prevents the wifi.cloned-mac-address global setting 
from taking effect. It will work fine if I create a new VM after the 
upgrade, so NM 1.4 doesn't encounter the old connection info. I suppose 
it might also work if I deleted the connections manually (though I'm not 
sure).


Chris

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

Re: Troubleshooting NM 1.4.0 (was 'How to activate...randomization?')

[Chris Laprise]

On 08/31/2016 01:16 PM, Thomas Haller wrote:

On Wed, 2016-08-31 at 12:07 -0400, Chris Laprise wrote:

I am trying out the new NM in Debian testing by installing the
network-manager 1.4.0-3 and network-manager-gnome 1.4.0-2 versions
from
unstable.


NM 1.4 shows up in the systray, but won't display any access points.
It
does seem to be trying to manage the wifi device, as its MAC address
now
changes to a random number; I can see this with ifconfig.


NM 1.2.4 had been working fine before the upgrade.


Any troubleshooting suggestions

Hi,


could be https://bugzilla.gnome.org/show_bug.cgi?id=770456
or https://bugzilla.gnome.org/show_bug.cgi?id=770504

please send the logfile with level=TRACE. Thanks

Thomas


Hi Thomas,

The patches appear to be working, as the new 1.4.2-1 release that landed 
in Debian testing is able to randomize both scanning and connections now.


However, it doesn't adhere to what is shown on the nm-settings man page. 
The assigned-mac-address setting is described as superceding the 
deprecated cloned-mac-address. But NM will only randomize during 
connections if cloned-mac-address is used.


wifi.assigned-mac-address=random

...has no effect, but

wifi.cloned-mac-address=random

...does work.

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

Troubleshooting NM 1.4.0 (was 'How to activate...randomization?')

[Chris Laprise]

I am trying out the new NM in Debian testing by installing the 
network-manager 1.4.0-3 and network-manager-gnome 1.4.0-2 versions from 
unstable.



NM 1.4 shows up in the systray, but won't display any access points. It 
does seem to be trying to manage the wifi device, as its MAC address now 
changes to a random number; I can see this with ifconfig.



NM 1.2.4 had been working fine before the upgrade.


Any troubleshooting suggestions?


Chris

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

Re: How to activate MAC address randomization?

[Chris Laprise]

On 08/30/2016 07:49 AM, Thomas Haller wrote:

Hi,

as a follow-up, I tried to explain the new options here:
https://blogs.gnome.org/thaller/2016/08/26/mac-address-spoofing-in-networkmanager-1-4-0/

Otherwise, our documentation should answer all your questions
-- if you don't understand something from our manual pages, we'd like
to improve them.


Thomas



The blog post does explain the 'stable' option pretty well, though the 
'Supported Modes' looks a little too terse to explain the new behaviors 
('stable' would seem to be a non-random option). At first glance, the 
expanded options look very useful.


But the new NM is not yet working for me... see new troubleshooting thread.


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

Re: How to activate MAC address randomization?

[Chris Laprise]

On 05/25/2016 10:56 AM, Dan Williams wrote:


NM always requests that non-associated scans (eg, before you've
connected to a wifi network) be randomized by default.  You can
(through the mac randomization property) request that the association
address also be randomized.

You can also use the cloned MAC address property to set a specific MAC
address for the association, on a per-connection basis.  If you choose
"always" for mac randomization, that overrides the cloned mac address.

As far as we know, and as far as we've tested, these both work
correctly when wpa_supplicant support exists and the driver uses the
nl80211 kernel API.  Out-of-tree and WEXT-based drivers may not work
correctly.

There does seem to be some confusion about the issue as you can see
from this thread, so we're trying to investigate that and clear things
up.  But when the features were added, they worked.

Dan



Hi Dan,

Is there more of a consensus now on this issue?

My last attempt at using NM 1.2 with wpas 2.4 and iwlwifi driver (which 
supposedly uses nl80211) resulted in NM saying it couldn't turn 
randomization on.


If I compile the latest NM 1.2 and wpas 2.5 master branches, should it 
work? My objective is to document the conditions and steps needed to get 
wifi randomization operational on Qubes OS, which is based on fedora.


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

Re: How to activate MAC address randomization?

[Chris Laprise]

On 05/25/2016 10:56 AM, Dan Williams wrote:

On Wed, 2016-05-18 at 21:10 -0400, Chris Laprise wrote:

On 05/18/2016 02:25 PM, Dan Williams wrote:


Randomization happens in the supplicant, and the supplicant also
controls scanning.  If randomization is enabled, the supplicant
will
change the MAC address before it scans, so this should not be a
problem.

Of course, if you run 'iw dev wlan0 scan' manually, that does not
go
through the supplicant, and you will leak your MAC.

If you use NM's MAC cloning functionality, then yes, that might
leak
your MAC because that only clones the MAC address for the duration
of
the connection to a specific access point.  It's not randomization,
it's the same as ethernet MAC cloning.

It does seem like a primary use case for randomization would be
random
addresses during scans only, and transition to chosen non-original
addresses for connections (per-AP). The users and admins aren't going
to
think to themselves: "We're going to assign different addresses to
these
connections, so we're OK with the hardware address coming through."
Not
if they're using pre-connection randomization (which should be
considered the operational norm by now).

And its not that connection randomization isn't important, too. I
just
think that pre-connection randomization would work very well towards
privacy if the 'randomization' were on a per-AP basis and not a
per-session basis (the latter being less compatible with some
institutional security schemes). Per-AP is more realistic and far
more
likely to be used.

So I would like to know if NM can coordinate with supplicant well
enough
to transition the NIC between randomized pre-connection scanning and
statically-spoofed connections without allowing the original address
to
be broadcast.

NM always requests that non-associated scans (eg, before you've
connected to a wifi network) be randomized by default.  You can
(through the mac randomization property) request that the association
address also be randomized.

You can also use the cloned MAC address property to set a specific MAC
address for the association, on a per-connection basis.  If you choose
"always" for mac randomization, that overrides the cloned mac address.

As far as we know, and as far as we've tested, these both work
correctly when wpa_supplicant support exists and the driver uses the
nl80211 kernel API.  Out-of-tree and WEXT-based drivers may not work
correctly.

There does seem to be some confusion about the issue as you can see
from this thread, so we're trying to investigate that and clear things
up.  But when the features were added, they worked.

Dan


Thanks to all of you for the clarifications and for addressing the 
remaining issues.


Chris

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

Re: How to activate MAC address randomization?

[Chris Laprise]

On 05/18/2016 02:25 PM, Dan Williams wrote:


Randomization happens in the supplicant, and the supplicant also
controls scanning.  If randomization is enabled, the supplicant will
change the MAC address before it scans, so this should not be a
problem.

Of course, if you run 'iw dev wlan0 scan' manually, that does not go
through the supplicant, and you will leak your MAC.

If you use NM's MAC cloning functionality, then yes, that might leak
your MAC because that only clones the MAC address for the duration of
the connection to a specific access point.  It's not randomization,
it's the same as ethernet MAC cloning.


It does seem like a primary use case for randomization would be random 
addresses during scans only, and transition to chosen non-original 
addresses for connections (per-AP). The users and admins aren't going to 
think to themselves: "We're going to assign different addresses to these 
connections, so we're OK with the hardware address coming through." Not 
if they're using pre-connection randomization (which should be 
considered the operational norm by now).


And its not that connection randomization isn't important, too. I just 
think that pre-connection randomization would work very well towards 
privacy if the 'randomization' were on a per-AP basis and not a 
per-session basis (the latter being less compatible with some 
institutional security schemes). Per-AP is more realistic and far more 
likely to be used.


So I would like to know if NM can coordinate with supplicant well enough 
to transition the NIC between randomized pre-connection scanning and 
statically-spoofed connections without allowing the original address to 
be broadcast.




If you're looking for a more generic MAC randomization feature that
also works for ethernet, then yes that would be NM's responsibility.
  Internally NM would handle ethernet MAC randomization itself, but
delegate to the supplicant for WiFi.  Since the supplicant handles
scanning, it must also handle WiFi MAC randomization to ensure
synchronization of the changes.

Dan


Ethernet is probably not as pressing a concern because of the physical 
link aspect, but thanks for the insight.


Chris

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

Re: How to activate MAC address randomization?

[Chris Laprise]

On 05/18/2016 08:24 AM, poma wrote:

On 18.05.2016 06:14, Chris Laprise wrote:


On 05/17/2016 07:36 PM, poma wrote:

On 16.05.2016 23:07, Chris Laprise wrote:

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


# grep rand /etc/NetworkManager/NetworkManager.conf
wifi.mac-address-randomization=2

# nmcli connection show WiFiRd | grep rand
802-11-wireless.mac-address-randomization:default

# journalctl -o cat -b -u NetworkManager | grep random
NetworkManager[2081]:   [...] sup-iface[[...],wlp0s2f1u3]: config: set 
MAC randomization to 1


The problem is that "rand-mac" does not work,
tested with patched 2.5 and 2.6-devel,
mt7601u and rt2800usb driven devices.


Does this leave us with fully functional pre-connection randomization
anyway? I would define 'full function' as the original mac addr not
being broadcast when Network Manager scans then connects using either of
the following:

1. A random address for any target AP
2. A static spoofed address for a predefined NM connection

The second case, at least, puts control of disclosure of the original
'hardware' address in the hands of the user. That is a big step in the
right direction.

I would also like to know if the second case is already possible with
the current unpatched releases of nm and wpas.

Many thanks,
Chris



2nd - 'cloned-mac-address' is there, if not from the very beginning
My concern here is just that some implementation detail will cause the 
original address to be announced anyway. For instance, mac addresses 
have a habit of reverting to original when waking a system from sleep. 
Conceivably, a scan could take place with original address before 
connection is re-established using assigned address.


So, a static spoofing function written for past use cases (which didn't 
grapple with concealment) may be different than a spoofing function that 
works to conceal original addresses.




1st - 'mac-address-randomization' i.e. "dynamic" version of the 2nd,
works like this - observing 'watch -n.1 macchanger -s wlp0s2f1u3'
it randomizes "Current MAC" value,
e.g.
Current MAC:   ea:1q:3w:z5:y8:ae  <=
Permanent MAC: 00:11:22:33:44:55

but during connection attempts it returns
to the original - "Permanent MAC" value,
e.g.
Current MAC:   00:11:22:33:44:55  <=
Permanent MAC: 00:11:22:33:44:55


But not quite simply a dynamic version of NM cloning, as NM didn't use 
macchanger. How hard would it be to move random number code into NM? 
Then it could have the same reliability as spoofing with a static address.


Chris

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

Re: How to activate MAC address randomization?

[Chris Laprise]

On 05/17/2016 07:36 PM, poma wrote:

On 16.05.2016 23:07, Chris Laprise wrote:


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


# grep rand /etc/NetworkManager/NetworkManager.conf
wifi.mac-address-randomization=2

# nmcli connection show WiFiRd | grep rand
802-11-wireless.mac-address-randomization:default

# journalctl -o cat -b -u NetworkManager | grep random
NetworkManager[2081]:   [...] sup-iface[[...],wlp0s2f1u3]: config: set 
MAC randomization to 1


The problem is that "rand-mac" does not work,
tested with patched 2.5 and 2.6-devel,
mt7601u and rt2800usb driven devices.

Does this leave us with fully functional pre-connection randomization 
anyway? I would define 'full function' as the original mac addr not 
being broadcast when Network Manager scans then connects using either of 
the following:


1. A random address for any target AP
2. A static spoofed address for a predefined NM connection

The second case, at least, puts control of disclosure of the original 
'hardware' address in the hands of the user. That is a big step in the 
right direction.


I would also like to know if the second case is already possible with 
the current unpatched releases of nm and wpas.


Many thanks,
Chris

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

Re: How to activate MAC address randomization?

[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?

[Chris Laprise]

On 05/12/2016 06:16 PM, 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



So there is no current release of wpa_supplicant that supports the 
randomization feature?


According to Lubomir Rintel and Michael Biebl the feature was released 
in 2.4.


https://blogs.gnome.org/lkundrak/2016/01/18/networkmanger-and-tracking-protection-in-wi-fi-networks/

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

Re: How to activate MAC address randomization?

[Chris Laprise]

On 04/29/2016 09:07 PM, Thomas Haller 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.

But its not clear what range of values should be specified here. The
nm-settings manpage suggests this is a valid way to turn on
randomization:


[connection]
wifi.mac-address-randomization=2

...in /etc/NetworkManager/NetworkManager.conf

However, it has no effect. I'm not sure what I'm missing here.

Hi,


How can you tell that it has no effect?


Hi,

I can tell its not randomizing when I check the address from ifconfig or 
'macchanger -s'. The original address is shown.



Setting default values in /etc/NetworkManager/NetworkManager.conf would
work, for that you need to leave the per-connection value at "default".
After editing the connection, you must always reload with `killall
-SIGHUP NetworkManager`.


So if my NetworkManager.conf looks like the following, it should work...?

   [main]
   plugins=keyfile

   [connection]
   wifi.mac-address-randomization=2

   [logging]
   #level=DEBUG
   [keyfile]
   unmanaged-devices=mac:fe:ff:ff:ff:ff:ff


The 'unmanaged' line is a reference to Qubes virtual interfaces; it 
should have no bearing on wifi.



mac-address-randomization requires support by Hardware and wpa-
supplicant. On Fedora23 I get a failure and the logfile reads:

   device (wlp3s0): Activation: (wifi) couldn't build wireless configuration: 
802-11-wireless: cannot enable mac-randomization due to missing supplicant 
support


Which log... dmesg or journalctl NetworkManager.service ?

The version of wpa_supplicant I have in f23 is 2.4. This should support 
the feature. But I think you're implying that iwlwifi and/or the 
hardware are also a factor. What would be helpful is a list of hardware 
and driver versions that are known to work with randomization.



Thomas


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

How to activate MAC address randomization?

[Chris Laprise]

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.

But its not clear what range of values should be specified here. The 
nm-settings manpage suggests this is a valid way to turn on randomization:



[connection]
wifi.mac-address-randomization=2


...in /etc/NetworkManager/NetworkManager.conf

However, it has no effect. I'm not sure what I'm missing here.

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