After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 630151 - add any way to use device with non-default MAC address ("spoofing")
add any way to use device with non-default MAC address ("spoofing")
Status: RESOLVED DUPLICATE of bug 553771
Product: NetworkManager
Classification: Platform
Component: general
0.8.x
Other All
: Normal enhancement
: ---
Assigned To: Dan Williams
Dan Williams
Depends on:
Blocks:
 
 
Reported: 2010-09-20 12:35 UTC by Sascha Silbe
Modified: 2010-09-20 17:11 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Sascha Silbe 2010-09-20 12:35:38 UTC 
Use case: I have a USB ethernet adapter that I plug into several different hosts. Each host should get its own, "static" IP address assigned via DHCP. The best way (read: the one compatible with all DHCP servers) to achieve this is to use a different (locally administered) MAC address on each host.

Currently there's no way to make this work with NetworkManager. I can change the MAC address with a script called by udev, but it introduces a race condition with NetworkManager:

- if the script starts without delay, changing the MAC address will conflict with NM setting the device up => MAC address unchanged
- if the script runs delayed and I don't MAC-bind the connection, changing the MAC address will conflict with NM setting the device up => MAC address unchanged
- if the script runs delayed and I MAC-bind the connection, the MAC address gets changed after NM has inspected the device => connection not brought up
Comment 1 Dan Williams 2010-09-20 16:09:57 UTC 
MAC spoofing was added to NM in late June, and will be part of the 0.8.2 release.  It also works better if your device's kernel driver supports the "permanent MAC" ethtool option (which reports the original MAC from the device's NVRAM even if the device's current MAC is changed), but it should also work without that driver support.

*** This bug has been marked as a duplicate of bug 553771 ***
Comment 2 Sascha Silbe 2010-09-20 17:11:36 UTC 
Sorry for the dupe, I didn't search for closed bugs. Nice to hear it's already implemented. Thanks & keep rolling!