There's two parts of the configuration involved: the subnet addresses
and the DNS information.
For the addressing, the shared (downlink) device signals the policy needs for a
/64 subnet. When it gets one, it merges it into the autoconf configuration and
forwards to the NDisc. When more prefixes are needed, the (uplink) device asks
the DHCP manager and eventually signals delegation (reception) of a prefix.
The NMDevice only provides the mechanism, the actual subnetting needs to
be done by the NMPolicy.
For the DNS configuration, the shared device just copies it from
whichever device the policy deems suitable.
Utilizes RFC 3633 prefix option in role of requesting router to ask the
delegating router for prefixes. In future we'll be able to use the
addresses from those prefixes on ipv6.method=shared connections.
This esentially causes us to announce the prefixes of the addresses we
own and the DNS configuration.
Currently the only way to get the IPv6 configuration on such device is
manual setting in the connection. This will change with IPv6 prefix
delegation.
The ndisc config can now be changed by NMDevice as well when the NDisc
is in ROUTER mode. But what we're really interested in is when we
receive a new one from the outside.
We'll soon not only do the router discovery, but announce ourselves as a
reouter. "Neighbor discovery" sounds to be a more appropriate name for
the class than "Router discovery".
For example for tun devices we get a lot of
(tun7): hw-addr: failed reading current MAC address
warnings. Just be silent about it. We log when something
changes, we don't need to log when we fail to obtain
a MAC address.
Thereby, refactor nm_device_update_hw_address() to return early.
The unmanaged flags PLATFORM_INIT indicates whether UDEV is done
initializing the device. We should not handle IP config changes
before that pointer.
This avoids codepaths that require the permanent MAC address of the
device. We should not freeze the permanent MAC address before
UDEV initialized the device, for two reasons:
- getting the permanent MAC address using ethtool is racy as
UDEV might still rename the interface.
- freezing a fake permanent MAC address should only happen after
UDEV is done configuring the MAC address of software devices.
#0 0x000055555568bc7a in nm_device_update_permanent_hw_address (self=self@entry=0x555555f0fb70 [NMDeviceVeth], force_freeze=force_freeze@entry=1) at src/devices/nm-device.c:11817
#1 0x000055555568c443 in nm_device_get_permanent_hw_address_full (self=self@entry=0x555555f0fb70 [NMDeviceVeth], force_freeze=force_freeze@entry=1, out_is_fake=out_is_fake@entry=0x0)
at src/devices/nm-device.c:12227
#2 0x000055555568cb06 in nm_device_get_permanent_hw_address (self=self@entry=0x555555f0fb70 [NMDeviceVeth]) at src/devices/nm-device.c:12237
#3 0x000055555568cb50 in spec_match_list (self=0x555555f0fb70 [NMDeviceVeth], specs=0x555555a5c000 = {...}) at src/devices/nm-device.c:12294
#4 0x00005555556a4ee6 in spec_match_list (device=0x555555f0fb70 [NMDeviceVeth], specs=0x555555a5c000 = {...}) at src/devices/nm-device-ethernet.c:1461
#5 0x00005555556978db in nm_device_spec_match_list (self=self@entry=0x555555f0fb70 [NMDeviceVeth], specs=0x555555a5c000 = {...}) at src/devices/nm-device.c:12277
#6 0x000055555558e187 in _match_section_infos_lookup (match_section_infos=0x555555a5d500, keyfile=0x555555a46f80, property=property@entry=0x555555793123 "ipv4.route-metric", device=device@entry=0x555555f0fb70 [NMDeviceVeth], out_value=out_value@entry=0x7fffffffe018) at src/nm-config-data.c:1169
#7 0x00005555555922ca in nm_config_data_get_connection_default (self=0x555555a548c0 [NMConfigData], property=property@entry=0x555555793123 "ipv4.route-metric", device=device@entry=0x555555f0fb70 [NMDeviceVeth]) at src/nm-config-data.c:1234
#8 0x00005555556790cd in _get_ipx_route_metric (self=self@entry=0x555555f0fb70 [NMDeviceVeth], is_v4=is_v4@entry=1) at src/devices/nm-device.c:1142
#9 0x000055555567912e in nm_device_get_ip4_route_metric (self=self@entry=0x555555f0fb70 [NMDeviceVeth]) at src/devices/nm-device.c:1161
#10 0x000055555567da6c in ip4_config_merge_and_apply (self=self@entry=0x555555f0fb70 [NMDeviceVeth], config=config@entry=0x0, commit=commit@entry=0, out_reason=out_reason@entry=0x0)
at src/devices/nm-device.c:4787
#11 0x000055555567e0fb in update_ip4_config (self=self@entry=0x555555f0fb70 [NMDeviceVeth], initial=initial@entry=0) at src/devices/nm-device.c:9532
#12 0x0000555555693acd in queued_ip4_config_change (user_data=0x555555f0fb70) at src/devices/nm-device.c:9651
#13 0x00007ffff4c966ba in g_main_context_dispatch (context=0x555555a46af0) at gmain.c:3154
#14 0x00007ffff4c966ba in g_main_context_dispatch (context=context@entry=0x555555a46af0) at gmain.c:3769
#15 0x00007ffff4c96a70 in g_main_context_iterate (context=0x555555a46af0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3840
#16 0x00007ffff4c96d92 in g_main_loop_run (loop=0x555555a47400) at gmain.c:4034
#17 0x000055555558372a in main (argc=<optimized out>, argv=<optimized out>) at src/main.c:411
Before the link is initialized, that is before UDEV completed
initializing the device, we should not evaluate the user-settings
unmanaged flags.
The reason is, that evaluating it likely involves looking at the
permanent MAC address, which might use the wrong fake MAC address
(before UDEV set the right one). Also, it might use the wrong ifname
to lookup the permanent MAC address via ethtool.
The permanent MAC address of an NMDevice shall not change as
long as the device is realized. That is, we read it only once
and don't change it afterwards.
There are two issues that this commit tries to mitigate:
(1) users are advised to use UDEV to rename interfaces. As we lookup
the permenent MAC address using ethtool (which uses the interface
name), there is a race where we could read the permanent MAC
address using the wrong interface name. We should wait until
UDEV finished initializing the device and until the interface
name is stable (see rh#1388286).
This commit still cannot avoid the race of ethtool entirely. It only
tries to avoid ethtool until UDEV has done its work. That is, until we
expect the interface name no longer to change.
(2) some device types, don't have a permanent MAC address so we fall
back to use the currently set address (fake). Again, users are advised
to use UDEV to configure the MAC addresses on such software devices.
Thus, we should not get the fake MAC address until UDEV initialized
the device.
This patch actually doesn't solve the problem at all yet.
The reason is that a regular caller of nm_device_get_permanent_hw_address() can
not afford to wait until UDEV settled. Thus, any user who requests the
permanent MAC address before the link is initialized, runs into the
problems above.
In a next step, we shall revisit such calls to nm_device_get_permanent_hw_address()
and delay them until the link is initialized.
We repeatedly call nm_device_update_hw_address() to reset the cached
MAC address of the device. However, we don't allow changing the address
length once it is set.
Multiple entities (initial, current and permanent MAC address) are all
checked to have the same address length. Changing the length would be a
very strange thing (and probably indicate a bug somewhere else).
Just don't allow that.
On devices that have no real permanent hardware address (as returned
by ethtool), we take the current MAC address of the device.
Currently, NM is a bit flaky about whether to accept such fake permanent
addresses for settings like keyfile.unmanaged-devices or the per-
connection property ethernet.mac-address. Probably, we should allow
using fake addresses there in general.
However, that leads to problems because NetworkManager itself changes
the current MAC address of such devices. For example when
configuing
keyfile.unmanaged-device=22:33:44:55:66:77
and later activating a connection with
ethernet.cloned-mac-address=22:33:44:55:66:77
we have a strange situation after restart and the device becomes
unmanaged.
We are going to avoid that, by remembering the fake permanent address
in the device state file.
This only matters:
- for devices that don't have a real permanent address (veth)
- if the user or NetworkManager itself changed the MAC address
of the device
- after a restart of NetworkManager, without reboot. A reboot
clears the device state for /var/run/NetworkManager.
_nm_utils_hwaddr_length() did a validation of the string
and returned the length of the address. In all cases where
we were interested in that, we also either want to validate
the address, get the address in binary form, or canonicalize
the address.
We can avoid these duplicate checks, by using _nm_utils_hwaddr_aton()
which both does the parsing and returning the length.
nm_settings_connection_set_autoconnect_blocked_reason() must be called
on the settings-connection. Fixes the following:
GLib-GObject-WARNING **: invalid cast from 'NMSimpleConnection' to 'NMSettingsConnection'
Fixes: 06da353242
We only needed proper glib enum types for having properties
and signal arguments. These got all converted to plain int,
so no longer generate such an enum type.
Had to rename "nm-enum-types.h" because it works badly with
"libnm/nm-enum-types.h". Maybe I could fix that differently,
but duplicate names is anyway error prone.
Note that "nm-core-enum-types.h" is already taken too, so
"nm-src-enum-types.h" it is.
We should enable tests by default, probably we even should drop
the configure flags to enable tests and just always build them.
Anyway, at this point there is no use in guarding check-local
with a check for ENABLE_TESTS. A user who does't want to run
the tests, should just not call `make check`.
Internal device types are a static thing. Let's not do a
constructor function to register the device factory.
This gets rid of all attribute((constructor)) functions inside
NetworkManager core. That is desired, because we don't want to
run code before main(). For example, at that point logging is
not yet initialized, but with code that runs before main() it
is hard to ensure that we don't log anything yet.
An interface would make sense to allow the actual device-factory to inherit
from another type.
However, glib interfaces make code much harder to follow and less
efficient. The device factory shall be a very simple type with meta data
about supported device types and the ability to create device instances.
There is no need to make this an interface implementation, instead just
let the factories inherit from NM_TYPE_DEVICE_FACTORY directly.
