Since commit 7d1709d7f6 ("device: check may_fail when progressing to
IP_CHECK") NM correctly checks the may-fail properties to decide
whether a connection must fail after the completion of IP
configuration. But for ipv4.method=disabled and ipv6.method=ignore the
IP configuration is always considered failed and thus setting
may-fail=no results in a connection that can never succeed.
To prevent such wrong configuration, force may-fail to TRUE for those
methods during connection normalization.
https://bugzilla.redhat.com/show_bug.cgi?id=1334884
NM_CONTROLLED=no is an explicit user configuration. There is no point in
issuing a warning that the user doesn't want to manage a device.
<warn> [1467722628.7388] ifcfg-rh: Ignoring connection /etc/sysconfig/network-scripts/ifcfg-eth0 (5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03,"System eth0") / device 'eth0' due to NM_CONTROLLED=no.
Also, don't truncate the device spec, instead show the full
device spec, it may contains a MAC address or a s390 subchannel.
No longer typedef NMDeviceEthernet to NMDevice. We don't do that
for most other classes, and I think it is not a good pattern
(yes, the casts are cumbersome, but what can you do).
Also, embed a pointer to the private data in NMDeviceEthernet
for fast lookup and ease of debugging.
We should overwrite the constructed() method instead of hooking the
GObject creation via constructed(). That is much cleaner as at that
point the GObject is fully initialized.
Also, this avoids a pointless warning when trying to get the not yet
initialized GUdevDevice:
<debug> [1467714778.0958] platform: signal: link added: 15: eth0 <DOWN;broadcast,multicast> mtu 1500 arp 1 ethernet? not-init addrgenmode eui64 addr AA:BB:CC:DD:EE:FF driver e1000e
<warn> [1467714778.0961] device (eth0): failed to find device 15 'eth0' with udev
<debug> [1467714778.0962] device[0x562eac10ee50] (eth0): constructed (NMDeviceEthernet)
...
<debug> [1467714778.1334] platform: signal: link changed: 15: enp0s25 <DOWN;broadcast,multicast> mtu 1500 arp 1 ethernet? init addrgenmode eui64 addr AA:BB:CC:DD:EE:FF driver e1000e
Trying to set a property on a device that does not exist is not something
necessarily wrong. Don't print error/warning messages.
<trace> [1467707267.2887] device[0x55a74adbdaf0] (enp0s25): set-hw-addr: setting MAC address to 'AA:BB:CC:DD:EE:FF' (reset, unmanage)...
<debug> [1467707267.2887] platform: link: setting '(null)' (2) hardware address
<debug> [1467707267.2887] platform-linux: link: change 2: address: 68:F7:28:61:68:F7 (6 bytes)
<debug> [1467707267.2887] platform-linux: do-request-link: 2
<debug> [1467707267.2888] platform-linux: netlink: recvmsg: error message from kernel: No such device (19) for request 226
<debug> [1467707267.2888] platform-linux: netlink: recvmsg: error message from kernel: No such device (19) for request 227
<error> [1467707267.2888] platform-linux: do-change-link[2]: failure changing link: failure 19 (No such device)
<warn> [1467707267.2888] device (enp0s25): set-hw-addr: failed to reset MAC address to 68:F7:28:61:68:F7 (unmanage)
The function name is no longer visible in the default
logging output. It is anyway only used together with
journal logging to set "CODE_FUNC".
Drop it. It allows to remove the strings from the binary,
which decreases the object size of a default build of NetworkManager
from 2437400 to 2412824 bytes (-24k, -1%).
When using g_return_val_if_reached(), the default macro would include
the function name. This name is increasing the binary size. Replace
it in non-debug builds.
The dhclient and dhcpcd clients can be destroyed during disposal of
the DHCP manager singleton and at that point the NMDhcpListener
singleton can be already gone. Reference it in the clients.
@buf_len is always initialized when @buf_arr is set but gcc fails to
recognize it:
../libnm-core/nm-keyfile-reader.c: In function 'mac_address_parser':
../libnm-core/nm-keyfile-reader.c:654:36: error: 'buf_len' may be used uninitialized in this function [-Werror=maybe-uninitialized]
tmp_string = nm_utils_hwaddr_ntoa (buf_arr, buf_len);
Fixes: 8eed67122c
On 32-bit architectures long and int have the same size and thus it's
wrong to use nmc_string_to_int() since it uses strtol() and the @max
argument can't represent G_MAXUINT32. Use nmc_string_to_uint()
instead.
https://bugzilla.redhat.com/show_bug.cgi?id=1350201
During shutdown, we unmanage Wi-Fi devices, and during NMDevice:deactivate()
we would reset to initial MAC address.
However, NMDeviceWifi:deactivate() would reset it again to the scanning one.
Fix that to properly restore the initial MAC address on the device
when NetworkManager exits.
Fixes: 4b2e375b33
Wi-Fi device first have a state-transition "disconnected -> prepare"
on which they run activate_stage1_device_prepare() and set the MAC
address the first time.
Later, after getting secrets, they have a state transition "need-auth ->
prepare" and end up calling nm_device_hw_addr_set_cloned() again. In this
case, we must not regenerate a new MAC address but bail out.
There is a small uncertainty there, because we are not sure that the previously
generated connection really entailed the same settings. But since we always
call nm_device_hw_addr_reset() during device deactivation, this cannot be
a left-over from a previous activation and is thus the same activation
request.
Instead of letting different subclasses call reset in their
virtual deactivate() function, do it in the parent class.
This works nicely, because the parent know whether the MAC
address is currently modified.
For the per-connection settings "ethernet.cloned-mac-address"
and "wifi.cloned-mac-address", and for the per-device setting
"wifi.scan-rand-mac-address", we may generate MAC addresses using
either the "random" or "stable" algorithm.
Add new properties "generate-mac-address-mask" that allow to configure
which bits of the MAC address will be scrambled.
By default, the "random" and "stable" algorithms scamble all bits
of the MAC address, including the OUI part and generate a locally-
administered, unicast address.
By specifying a MAC address mask, we can now configure to perserve
parts of the current MAC address of the device. For example, setting
"FF:FF:FF:00:00:00" will preserve the first 3 octects of the current
MAC address.
One can also explicitly specify a MAC address to use instead of the
current MAC address. For example, "FF:FF:FF:00:00:00 68:F7:28:00:00:00"
sets the OUI part of the MAC address to "68:F7:28" while scrambling
the last 3 octects.
Similarly, "02:00:00:00:00:00 00:00:00:00:00:00" will scamble
all bits of the MAC address, except clearing the second-least
significant bit. Thus, creating a burned-in address, globally
administered.
One can also supply a list of MAC addresses like
"FF:FF:FF:00:00:00 68:F7:28:00:00:00 00:0C:29:00:00:00 ..." in which
case a MAC address is choosen randomly.
To fully scamble the MAC address one can configure
"02:00:00:00:00:00 00:00:00:00:00:00 02:00:00:00:00:00".
which also randomly creates either a locally or globally administered
address.
With this, the following macchanger options can be implemented:
`macchanger --random`
This is the default if no mask is configured.
-> ""
while is the same as:
-> "00:00:00:00:00:00"
-> "02:00:00:00:00:00 02:00:00:00:00:00"
`macchanger --random --bia`
-> "02:00:00:00:00:00 00:00:00:00:00:00"
`macchanger --ending`
This option cannot be fully implemented, because macchanger
uses the current MAC address but also implies --bia.
-> "FF:FF:FF:00:00:00"
This would yields the same result only if the current MAC address
is already a burned-in address too. Otherwise, it has not the same
effect as --ending.
-> "FF:FF:FF:00:00:00 <MAC_ADDR>"
Alternatively, instead of using the current MAC address,
spell the OUI part out. But again, that is not really the
same as macchanger does because you explictly have to name
the OUI part to use.
`machanger --another`
`machanger --another_any`
-> "FF:FF:FF:00:00:00 <MAC_ADDR> <MAC_ADDR> ..."
"$(printf "FF:FF:FF:00:00:00 %s\n" "$(sed -n 's/^\([0-9a-fA-F][0-9a-fA-F]\) \([0-9a-fA-F][0-9a-fA-F]\) \([0-9a-fA-F][0-9a-fA-F]\) .*/\1:\2:\3:00:00:00/p' /usr/share/macchanger/wireless.list | xargs)")"
Add new virtual function nm_device_unmanage_on_quit() to determine
whether to unmanage the device on shutdown.
This allows Wi-Fi devices to always be unmanaged. We want that to
reset the initial MAC address.
This allows the user to disable MAC address randomization during
scanning for Wi-Fi networks, which is done by default.
For one, this allows the user to disable the randomization for whatever
reason.
Also, together with configuring the per-connection setting
wifi.cloned-mac-address=preserve, this allows to disable NetworkManager
to modify the MAC address of the interface. This may allow the user
to set the MAC address outside of NetworkManager without NetworkManager
interfering.
'wireless.mac-address-randomization' broke 'wireless.cloned-mac-address',
because we would always set 'PreassocMacAddr=1'. The reason is that
supplicant would set 'wpa_s->mac_addr_changed' during scanning, and
later during association it would either set a random MAC address or
reset the permanent MAC address [1].
Anyway, 'wireless.mac-address-randomization' conflicts with
'wireless.cloned-mac-address'. Instead of letting supplicant set the
MAC address, manage the MAC addresses entirely from NetworkManager.
Supplicant should not touch it.
[1] https://w1.fi/cgit/hostap/tree/wpa_supplicant/wpa_supplicant.c?id=f885b8e97cf39b56fe7ca6577890f2d20df7ae08#n1663
When a user want to explicitly spoof the MAC address, a failure
to do so should fail activation. For one, failing to do so may
be a security problem. In any case, if user asks to configure the
interface in a certain way and we fail to do so that shall result
in a failure to activate.
Extend the "ethernet.cloned-mac-address" and "wifi.cloned-mac-address"
settings. Instead of specifying an explicit MAC address, the additional
special values "permanent", "preserve", "random", "random-bia", "stable" and
"stable-bia" are supported.
"permanent" means to use the permanent hardware address. Previously that
was the default if no explict cloned-mac-address was set. The default is
thus still "permanent", but it can be overwritten by global
configuration.
"preserve" means not to configure the MAC address when activating the
device. That was actually the default behavior before introducing MAC
address handling with commit 1b49f941a6.
"random" and "random-bia" use a randomized MAC address for each
connection. "stable" and "stable-bia" use a generated, stable
address based on some token. The "bia" suffix says to generate a
burned-in address. The stable method by default uses as token the
connection UUID, but the token can be explicitly choosen via
"stable:<TOKEN>" and "stable-bia:<TOKEN>".
On a D-Bus level, the "cloned-mac-address" is a bytestring and thus
cannot express the new forms. It is replaced by the new
"assigned-mac-address" field. For the GObject property, libnm's API,
nmcli, keyfile, etc. the old name "cloned-mac-address" is still used.
Deprecating the old field seems more complicated then just extending
the use of the existing "cloned-mac-address" field, although the name
doesn't match well with the extended meaning.
There is some overlap with the "wifi.mac-address-randomization" setting.
https://bugzilla.gnome.org/show_bug.cgi?id=705545https://bugzilla.gnome.org/show_bug.cgi?id=708820https://bugzilla.gnome.org/show_bug.cgi?id=758301
Note that usually for infiniband we cannot get a permanent MAC address
via ethtool. Thus, nm_device_get_permanent_hw_address() will return the
current address due to fallback_fake=TRUE.
VLAN and MACVLAN devices consider an ethernet.mac-address setting
to find the parent device. This setting shall be the permanent MAC
address of the device, not the current.
`man nm-settings` says about ethernet.mac-address:
If specified, this connection will only apply to the Ethernet device
whose permanent MAC address matches.
Using the current, possibly non-permanent MAC address doesn't really
make sense.
Also, NM_DEVICE_HW_ADDRESS used to be writable and was set by NMDeviceBt
to the bdaddr. That is wrong, because bdaddr should not be the current
address, but the permanent one.
When we were able to read a MAC address previously, we would not expect
a failure the next time.
Say a failure happens. Still, we should not clear the MAC address,
because we also determine hw_addr_len based on that address. And
hw_addr_perm and hw_addr_initial have the same length. When we allow
hw_addr to be reset (and possibly reset to a different address length),
we somehow have to re-fresh also the permanent and initial MAC address.
Just don't allow for that complexity, when it's not even clear what such
a scenario would mean and what do to in that case.
Both NMDeviceEthernet and NMDeviceWifi have a property "perm-hw-address".
As the hw_addr_perm property is tracked in the parent NMDevice class,
let it also implement the GObject property.
Then it knows better when to emit a notification about property
changes.
While a device is realized, we only want to read the permanent
MAC address once. If that fails, we fallback to the current MAC
address. Thus, we want the permanent address be stable until
the device unrealizes.
While we want to fallback to the current MAC address, in some cases
the caller wants to know whether this was a "real" permanent MAC
address as read via ethtool.
For example, when matching an ethernet device against ethernet.mac-address
property, the fake (current) address should not be used in such case.
Next I will add two more fields. Being able to efficiently grep the code
is important.
I want to be able to grep for "->hw_addr" or "\<hw_addr" to find
related stuff.
Unfortunately, prefixes often result in backward English names, e.g.
hw_addr_set/hw_addr_get. I still prefer that over get_hw_addr/set_hw_addr
though.
