Instead of reimplementing the slave property in bond, bridge
and team, just add the property to the parent class. It's not
that the parent class would be agnostic to the master/slave
implementation, all the slaves are known to the every device
type implementation.
Also, the derived class doesn't know the correct time when
to invoke the notify-changed for the slaves property.
E.g. it should be only invoked after nm_device_slave_notify_enslave()
when other components also consider the slave as enslaved.
Later this will be fixed so that the SLAVES property correspond
to what other master/slave related properties say.
(gdb) bt
#0 0x00007fc1c920681b in g_logv () at /lib64/libglib-2.0.so.0
#1 0x00007fc1c920698f in g_log () at /lib64/libglib-2.0.so.0
#2 0x00007fc1c9523237 in g_type_check_instance_cast () at /lib64/libgobject-2.0.so.0
#3 0x00007fc1bdef10ed in supplicant_connection_timeout_cb (user_data=0x561a52451600) at nm-device-wifi.c:2207
#4 0x00007fc1c9200893 in g_timeout_dispatch () at /lib64/libglib-2.0.so.0
#5 0x00007fc1c91ffe3a in g_main_context_dispatch () at /lib64/libglib-2.0.so.0
#6 0x00007fc1c92001d0 in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0
#7 0x00007fc1c92004f2 in g_main_loop_run () at /lib64/libglib-2.0.so.0
#8 0x0000561a511583f3 in main (argc=1, argv=0x7ffc033f1e28) at main.c:488
dhclient adds a trailing dot to domain search list entries received
from the server, while the same domains received by other means
(dhcpcd on RA) don't have the final dot. The result is that
resolv.conf can be populated with duplicated entries.
Fix this by stripping the trailing dot when a new search domain is
added to a IP configuration.
https://bugzilla.gnome.org/show_bug.cgi?id=758777
release_slave() should do the right thing and handle errors as
good as it can. There is no value in propagating the error and
it's not clear what the caller should do in face of a failure
during release.
We have the master/slave related functions
- for master device:
- nm_device_master_add_slave()
- nm_device_master_release_slaves()
- nm_device_release_one_slave()
- nm_device_enslave_slave()
- for slave device:
- nm_device_slave_notify_enslave()
- nm_device_slave_notify_release()
Rename the two that didn't match the pattern to
- nm_device_master_release_one_slave()
- nm_device_master_enslave_slave()
We don't want to admin CAP_SYS_ADMIN to our capability set in our .service
file: If we're running with systemd then hostnamed should be used to manage the
hostname, otherwise we likely have all capabilities anyway.
Let the user know.
Really, use systemd-hostnamed. Use it.
It's clearer to (always) subscribe early to the NM_DEVICE_RECHECK_ASSUME signal
instead of during realize. Also, because a device can be realized several times.
Just make sure that recheck_assume_connection() doesn't do anything if it shouldn't
handle the event.
Only downside is some unnecessary work when there is nothing to do.
Also fix the signature of the NM_DEVICE_RECHECK_ASSUME handler recheck_assume_connection().
NM_DEVICE_RECHECK_ASSUME signal returns void. We should not subscribe recheck_assume_connection()
which returns gboolean.
But, of course, only one realized device can have the same
interface name at a time.
This commit effectively reverts most of:
1b37cd0340
core: allow ActiveConnections to be created without a device
But it's not easy to do a separate revert of that code due to
interdependencies with nm-manager.c.
Creating devices when they are defined by a connection also makes
makes it possible to require the NMDevice to be present when
activating it, which means we can remove a bunch of code from
NMManager that had to handle software devices not existing yet at
the time of the activation request.
But it also means we must be more careful when finding master
interfaces during slave activation, since we cannot simply match
by interface name alone. Instead we must find the master which
matches both the interface name and can control slaves of the type
which is being activated.
Ensure the platform link with the same interface name as the
NMDevice is actually compatible with it before using the link
for initialization of device properties. If not, remove the
NMDevice and create a new one since there are kernel resources
with a different type.
Unrealized devices aren't backed by kernel resources and so won't know
all of their attributes. That means three things:
1) they must update their attributes when they become realized
2) they must clear those attributes when unrealized
3) they must be looser in checking compatible connections until
they are realized
This requires that the setup() function be split into two parts, start & finish,
because finish must be run after add_device()
Also, we can simplify whether to pay attention to 'recheck-assume', which
is now dependent on priv->is_nm_owned, because the only case where NM should
*not* listen for the 'recheck-assume' signal is when the device is a
software device created by NM itself. That logic was previously spread
across the callers of add_device() but is now consolidated into
nm-manager.c::device_realized() and nm-device.c::nm_device_create_and_realize().
The device properties are obtained via netlink, thus we get proper
platform notifications whenever they change. So the device properties
always reflect the platform state and there is no need to refresh
it during update_connection()/check_connection_compatible().
This property is TRUE for devices that exist either as a kernel device
or are backed by some other resource (eg, ModemManager object, Bluez
device, etc). It will eventually be FALSE for software devices that
are not yet instantiated.
There is only one user of the NM_DEVICE_MASTER property (NMActiveConnection).
device_master_changed() uses the property for change notifications,
but returns early if !nm_device_get_master().
We might emit the "notify::master" signal too often, even when nothing
changed (because currently we always emit it when priv->master changes).
If we would fix that to only emit the signal when nm_device_get_master()
actually changes, it would still be correct, because device_master_changed()
doesn't care about notifications when the master is unset.
Hence, the only user doesn't care about the difference. So change it because
it's unexpected that the property and function are not completely equal.
Commit cd3df12c8f reused the
virtual function component_added() to notify the vlan device
about a possibly new parent.
This reuse of the virtual function for another purpose is confusing.
Clean that up by splitting the implementation and add a new
virtual function nm_device_notify_new_device_added() which gets
(only implemented by NMDeviceVlan).
When deleting a master-device either via `nmcli device delete`
or `ip link delete`, the slave-device would hang.
This seems to be broken for a very long time already.
This is due to the following:
#0 0x00005555555f548c in nm_device_slave_notify_release (self=0x555555dc1300, reason=NM_DEVICE_STATE_REASON_NONE) at devices/nm-device.c:2175
#1 0x00005555555d6de2 in nm_device_release_one_slave (self=0x555555de3dd0, slave=0x555555dc1300, configure=0, reason=NM_DEVICE_STATE_REASON_NONE) at devices/nm-device.c:1117
#2 0x00005555555f02b7 in device_link_changed (self=0x555555dc1300) at devices/nm-device.c:1460
Previously, nm_device_slave_notify_release() being called with reason
"NONE" did not actually transition the device-state, thus keeping the
device wrongly in activated state.
There were two callers that passed configure=FALSE to nm_device_release_one_slave(),
(and thus reason=NONE to nm_device_slave_notify_release()):
- (1) device_link_changed():
nm_device_release_one_slave (priv->master, self, FALSE, /*wrong reason NONE*/);
- (2) nm_device_removed():
nm_device_release_one_slave (priv->master, self, FALSE, NM_DEVICE_STATE_REASON_REMOVED);
We should always change the device-state during nm_device_slave_notify_release()
regardless of the reason.
(2) was added by commit c83b40aca7, later
refined by commit 5dd48f7527. In a way
change the second fix to perform some of the configuration (but still
not unenslaving the device).
Check if 'ipip' and 'ip6_tunnel' modules are loaded when trying to
perform link tests that require them and skip the tests if the modules
are not available.
Fixes: 133724d958
Fixes: 1a3448b43b
The new object type represents tunnels over IPv4 and IPv6.
We have a single setting type (NMSettingIPTunnel) for tunnels and it
can't be shared among different device factories. So we define also a
single device type for all tunnels.
This new object will also represent GRE tunnels, which before were
instantiated as NMDeviceGre and had a ".Device.Gre" D-Bus
interface. This commit introduces a change in behavior.
@random_data is declared as _cleanup_free_.
Freeing it is unnecessary and freeing without clearing the
pointer leads do a double free.
This reverts commit 3d1557eaad.
