Since nm_device_slave_notify_release() is called from outside the
activation chain of the slave device (it gets called from the master
device) there might be pending activation sources scheduled, clear
them before queueing a state change.
If the device is disconnected because it can't be assumed due to lack
of IP configuration, don't try to generate an ipv6 link-local address,
as this requires a connection.
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
#1 __GI_abort () at abort.c:89
#2 g_assertion_message (domain=domain@entry=0x5f41b4 "NetworkManager", file=file@entry=0x5ef9b5 "devices/nm-device.c", line=line@entry=831,
func=func@entry=0x5f3220 <__FUNCTION__.37383> "nm_device_get_ip_iface_identifier", message=message@entry=0x1e86100 "assertion failed: (connection)") at gtestutils.c:2429
#3 g_assertion_message_expr (domain=domain@entry=0x5f41b4 "NetworkManager", file=file@entry=0x5ef9b5 "devices/nm-device.c", line=line@entry=831,
func=func@entry=0x5f3220 <__FUNCTION__.37383> "nm_device_get_ip_iface_identifier", expr=expr@entry=0x5e65c6 "connection") at gtestutils.c:2452
#4 nm_device_get_ip_iface_identifier (self=self@entry=0x1e612a0, iid=iid@entry=0x7fffce40e3d0, ignore_token=ignore_token@entry=1) at devices/nm-device.c:831
#5 check_and_add_ipv6ll_addr (self=self@entry=0x1e612a0) at devices/nm-device.c:5983
#6 queued_ip6_config_change (user_data=0x1e612a0) at devices/nm-device.c:9489
#7 g_main_dispatch (context=0x1d3e060) at gmain.c:3154
#8 g_main_context_dispatch (context=context@entry=0x1d3e060) at gmain.c:3769
#9 g_main_context_iterate (context=0x1d3e060, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3840
#10 g_main_loop_run (loop=0x1d3ab00) at gmain.c:4034
#11 main (argc=1, argv=0x7fffce40e6a8) at main.c:411
https://bugzilla.redhat.com/show_bug.cgi?id=1351633
<info> [1467793329.6313] device (veth-guest): Activation: starting connection 'my-wired' (ca058ec5-8a47-4e1e-b38e-962b71c4699e)
<debug> [1467793329.6313] device[0x55af2884bf90] (veth-guest): activation-stage: schedule activate_stage1_device_prepare,2 (id 510)
<warn> [1467793329.6314] device (veth-guest): disconnecting connection 'my-wired' for new activation request.
<info> [1467793329.6315] device (veth-guest): state change: disconnected -> deactivating (reason 'new-activation') [30 110 60
A warning is too verbose. This is not an unusual condition, it's just that
a new activation supersedes an other one.
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)
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.
'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
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
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.
Previously, we would only once read the initial hardware address during
device realization.
When a device activates, NetworkManager always sets the MAC address as configured
in the cloned-mac-address setting -- or, if unspecified -- it falls back
to use the permanent hardware-address instead.
Later, when deactivating the device, the MAC address is reset to the
"inital MAC address".
This patch changes, that the "initial MAC address" is re-read every time
before activating the device, contrary to reading it once in the
beginning.
This allows for a user to first start NetworkManager and later change the
MAC address of the device. When activating the device, NM will reset the
MAC address for the time the device is active. But when disconnecting,
it resets to the user-changed value, not the value when NM was started.
https://bugzilla.gnome.org/show_bug.cgi?id=708820
The current MAC address is part of NMPlatformLink in the platform cache.
When it changes, we must update the device's current value.
Also, the MAC address of NMDeviceEthernet is exposed on D-Bus. That
property should show the currently configured MAC address, not a state
that was read some time in the past.
Also, nm_device_hw_addr_set() compares the current MAC address before
resetting it. If that field is out-of-date, nm_device_hw_addr_set() will
behave wrongly.
NMDeviceEthernet had some special handling in link_changed() that would
re-read the MAC addresses and possibly bring up the interface. Move that
code to the parent device.
hw-addr is a constuct-only property. We should not do complex stuff in the property
setter before the object is sufficiently initialized. For example, the logging
macros access nm_device_get_iface(), which might be unset at that early
point.
Instead, initialize hw_addr and hw_addr_len later, at the end of the constructor()
function.
Also, ensure that @hw_addr_len is zero iff @hw_addr is unset.
Also, ensure that we always log a message when changing/setting the
hardware address -- except when clearing it during unrealize. It's
implicit that unrealize clears the hardware address.
Also, give all related logging messages a "hw-addr:" prefix.
Accessing the platform cache might anytime yield unexpected results.
E.g. the link could be gone, or the ifindex could even be replaced
by a different interface (yes, that can happen when moving links
between network namespaces).
It's not clear how to handle such a case at runtime. It seems wrong to
me to just error out. Still, such case might happen under normal
conditions, so it's wrong to just warn and proceed.
There was no leak here, because we would only call
nm_device_update_initial_hw_address() when @initial_hw_addr is unset.
However, still clear it to make it more robust against later changes.
The Network_ID for generating RFC 7217 stable privacy IPv6 addresses
is by default the UUID of the connection.
Alternatively, prefer "connection.stable-id" as Network_ID to generate
the stable addresses. This allows to configure a set of connections that
all use the same Network_ID for generating stable addresses.
Note that the stable-id and the UUID do no overlap, that is two
connections
[connection]
uuid=uuid1
stable-id=
and
[connection]
uuid=uuid2
stable-id=uuid1
generate distinct addresses.
For changing the hardware address, we must bring the device down. When doing
that, IP addressing is lost and it must be re-configured after bringing the
device up again.
We already do something similar in device_link_changed(), but that might
not be sufficient, because device_link_changed() is run on an idle
handler, thus, while changing the hardware address it has no chance to
run (or notice that the device was shortly down).
https://bugzilla.redhat.com/show_bug.cgi?id=1309899
Instead of accessing the singleton getter nm_settings_get(), obtain
the settings instance from the device instance itself via
nm_device_get_settings().
Currently NM proceeds with the activation of a device just after the
IPv6 configuration is applied. Server applications will bind to IPv6
addresses as soon as NM signals the presence of network connectivity,
but since the addresses are still tentative the bind will fail. There
are a couple of solutions to this.
Linux kernel supports "optimistic DAD", which is a modification of
Neighbor Discovery and SLAAC processes that allows addresses to be
used (under certain contraints) while kernel is performing DAD on
them. However it is not feasible to let NM enable optimistic DAD for
the devices it controls for the following reasons:
- it is not guaranteed to be always available since it can be turned
off at compile time
- RFC 4429 states that it should not be used for manually entered
addresses
- it works only with autoconf addresses generated by kernel
Therefore, use a different approach and handle this in NM by waiting
that the kernel completes DAD before continuing activation. We build a
list of addresses that are tentative just after the new configuration
is applied and then we asynchronously wait a platform address-change
event where all NM-configured addresses become non-tentative.
A similar solution has been adopted also by other network managing
tools:
https://anonscm.debian.org/cgit/collab-maint/ifupdown.git/commit/?id=ec357a5d6cb5fa8b0004c727d7cc48253c59eb0f8012cd3919https://bugzilla.redhat.com/show_bug.cgi?id=1243958
