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.
When the entire NMSettingWired setting is missing, it should be treated
exactly the same as each property having the default/unset value.
Otherwise, adding a NMSettingWired setting only to set (say) MTU,
would result in different behavior. Although effectively the
"cloned-mac-address" shall be in both cases the same.
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.
Avoids the following error when ofono isn't running:
NetworkManager[25133]: <info> [1466186144.1392] ofono is now available
NetworkManager[25133]: <warn> [1466186144.1637] failed to enumerate oFono devices: Cannot invoke method; proxy is for a well-known name without an owner and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag
because the code assumes that if the GDBusProxy is created, that
oFono is available. That's not the case with DO_NOT_AUTO_START
because it creates the proxy anyway, and lets the caller listen
for name-owner-changed signals instead. The GDBusProxy also
doesn't need to be cleared, since it will follow name-owner
changes and emit g-name-owner changes when oFono starts/stops.
This also fixes the oFono name-owner-changed watch. It was presumably
using the signal name copied from the ModemManager 'notify::name-owner'
code, but that's a GDBusObjectManagerClient. The oFono code is using
a GDBusProxy for which the signal is 'notify::g-name-owner'.
Finally, the oFono code shouldn't really be piggy-backing on the
ModemManager autolaunch code, it's just cleaner to keep the two
code paths separate and initialize oFono in parallel.
NM_MODEM_UID is used as the modem device name, and the device name
cannot contain path-like characters.
Ofono has a bluez plugin that detects paired DUN/PAN capable
Bluetooth devices, and these devices are created with a multi-component
object path like "/hfp/org/bluez/hci0/dev_00_26_E2_AB_68_66".
The NM ofono plugin cannot use these paths as NM device names.
Instead, strip off any path components and use the last part
of the object path as the NM device name.
Software devices must report the NM_DEVICE_CAP_IS_SOFTWARE capability
in order to be properly activated. Add the flag to NMDeviceTun and
NMDeviceVxlan.
https://bugzilla.gnome.org/show_bug.cgi?id=767846
It's possible for wpa_supplicant to transition to INACTIVE
state with an outstanding requested_scan pending. This can
lead to a stall condition where scanning no longer occurs.
[thaller@redhat.com: added break statement to avoid fall-through]
https://mail.gnome.org/archives/networkmanager-list/2016-June/msg00116.html
