If a slave device activates, we should keep the master up even though it
was taken over before.
This fixes an issue, where a single slave to a master would be
reactivated after a daemon restart. The daemon restart would cause the
master to be treated externally created (would go unmanaged when all the
slaves are gone) while the reactivation would leave the master without
slaves for a while.
(cherry picked from commit b605fb2712)
The only implementations were there for tracking the parent device.
That is now donw via nm_device_parent_*(), parent_changed_notify()
and _parent_notify_changed().
Multiple subclasses have a parent/link interface (NMDeviceIPTunnel,
NMDeviceVlan). Tracking the parent interface properly is midly
complicated to get right. So, instead of repeating it in each
subclass, track it in the parent device.
nm_settings_add_connection_dbus() invokes the activation_add_done()
callback with a NULL @new_connection in case of error: add a check to
prevent a crash.
We used MASTER, BRIDGE and TEAM_MASTER keys for a differnet purpose than the
network.service did, confusing the legacy tooling. Let's do our best to write
compatible configuration files:
* Add *_UUID properties that won't clash with initscripts
* Ignore non-*_UUID keys on read if *_UUID is present
* If the connection.master is an UUID of a connection with a
connection.interface-name, write the uuid into the *_UUID key while setting
the non-*_UUID key to the interface name for compatibility
https://bugzilla.redhat.com/show_bug.cgi?id=1369091
If a connection is ACTIVATED and another one is ACTIVATING but there
is no global connectivity, we currently set the manager state to
CONNECTING and start a connectivity check to verify whether the
manager state can be promoted to CONNECTED_GLOBAL.
If this connectivity check fails, we shouldn't promote a CONNECTING
state to CONNECTED_SITE.
Fixes: 084da69a30
The manager state is already computed every time an active connection
changes state, it is not necessary to call nm_manager_update_state()
also when the property is read.
Moreover, nm_manager_update_state() emits a "notify::state" signal
which causes a re-read of the property by the nm-exported-object,
resulting in a nested execution of nm_manager_update_state().
When going to sleep, we unmanage devices setting the unmanaged flags
immediately but delaying the state transition (because we do it from
another state transition). The signal handler can be executed after
the wake and, especially, after we have already re-managed the device,
making the device unmanaged again.
Detect such situation and force the state to UNMANAGED (which will
also clear any pending state change), so that later we manage the
device again and it will try to activate any available connection.
Fixes: 81ea812362https://bugzilla.redhat.com/show_bug.cgi?id=1382526
This makes it easier to install the files with proper names.
Also, it makes the makefile rules slightly simpler.
Lastly, the documentation is now generated into docs/api, which makes it
possible to get rid of the awkward relative file names in docbook.
Keep the include paths clean and separate. We use directories to group source
files together. That makes sense (I guess), but then we should use this
grouping also when including files. Thus require to #include files with their
path relative to "src/".
Also, we build various artifacts from the "src/" tree. Instead of having
individual CFLAGS for each artifact in Makefile.am, the CFLAGS should be
unified. Previously, the CFLAGS for each artifact differ and are inconsistent
in which paths they add to the search path. Fix the inconsistency by just
don't add the paths at all.
The interaction between the manager state and connectivity check code
is tricky. When there is an active connection with a default route and
NMConnectivity reports full connectivity, we set the CONNECTED_GLOBAL
state. However, if the connectivity check hasn't run yet, we stay in
CONNECTED_SITE state. If there are also other connections that are
activating, the state is set to CONNECTING.
This is a problem, because in CONNECTING we never run the connectivity
check and thus we fail to recognize that there is full connectivity
until a periodic check is run.
To solve this, schedule the connectivity check every time there is an
active connection with default route, even if other connection are
still activating, so that the check result can make the state progress
to CONNECTED_GLOBAL.
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.
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.
Since connection.autoconnect-slaves was introduced, we only allowed it
to autoactivate slaves for connections that were not slave themselves.
It seems useful to remove such limitation, but we must prevent an
infinite loop if there is a circular dependency between connections.
https://bugzilla.redhat.com/show_bug.cgi?id=1360386
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.
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.
- use _NM_GET_PRIVATE() and _NM_GET_PRIVATE_PTR() everywhere.
- reorder statements, to have GObject related functions (init, dispose,
constructed) at the bottom of each file and in a consistent order w.r.t.
each other.
- unify whitespaces in signal and properties declarations.
- use NM_GOBJECT_PROPERTIES_DEFINE() and _notify()
- drop unused signal slots in class structures
- drop unused header files for device factories
No need for the setter/getter of this property.
Immutable properties are so much nicer. Remove the setter and
ensure that the nm_plugin_missing property is only set during
object construction.
The data is still unused, the actual fields might change.
Note that the actual state we store is subject to change,
according to which data we need. The file format is non stable,
as the files don't survive reboot. So there is no backward
compatibility to maintain and the format can be changed later.
And drop the unused function nm_manager_check_capability().
I don't think we need such a function server-side, as the
server usually has better ways to check whether a capability
is supported.
dispose() must be re-entrant. Thus, at the very least it must clear the
priv->capabilities after freeing the array.
While at it, move it to finalize (which is only called once) and
move initialization of the array from "constructed" to nm_manager_init()
which is called first.
The 'device-added' and 'device-removed' signals indicate when the
value of the 'Devices' property changes. The property only returns
realized devices and so if a device unrealizes we should emit the
removed signal for it.
Fixes: 5da37a129chttps://bugzilla.gnome.org/show_bug.cgi?id=771324
Commit 4c7fa8dfdc ("core: drop root requirement for
load_connection(s)/set_logging D-Bus calls") removed the enforcing of
permission in the daemon for such methods since the D-Bus daemon
configuration already does that. That change also allows clients to
send a request and not wait for a response, since we don't have to
check the caller credentials in the daemon.
In the future we might switch to polkit for these methods, breaking
clients that don't wait for a reponse, so it seems better to prevent
from beginning such behavior.
Fixes: 4c7fa8dfdc
(cherry picked from commit dd27b79c4e)
The D-Bus configuration already ensures that only root can do that;
enforcing the permission at policy level seems better than doing it in
the daemon itself because it allows users to change the policy and
also because callers can exit immediately after issuing the request.
(cherry picked from commit 4c7fa8dfdc)
Technically, this is not needed because glib requires that
int is at least 32 bits. Thus, uint32 will be safely promoted
to uint.
Just do the cast to be explict about the expected type.
