On Wed, 2016-05-18 at 11:21 -0400, Chris Laprise wrote: > > 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=e50c50d5a090a6a52af6d > > > > > > > 92ee3a3c9cc37743747 > > > > > > > > > > > > > > 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]: <info> [...] 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.
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. > 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. 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 _______________________________________________ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
