- cleanup _NMLOG()
- implement state_to_string() based on NM_UTILS_STRING_LOOKUP_TABLE(),
which prints unknown values as numeric
- add logging when setting device and state
- cleanup logging in check-master-ready to consistently
print relevant information
- update logging in set_master() to match simpler logging
format like set_device() and set_state().
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.
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().
Clone the connection upon activation. This makes it safe for the user
to modify the original connection while it is activated.
This involves several changes:
- NMActiveConnection gets @settings_connection and @applied_connection.
To support add-and-activate, we constructing a NMActiveConnection with
no connection set. Previously, we would set the "connection" field to
a temporary NMConnection. Now NMManager piggybacks this temporary
connection as object-data (TAG_ACTIVE_CONNETION_ADD_AND_ACTIVATE).
- get rid of the functions nm_active_connection_get_connection_type()
and nm_active_connection_get_connection_uuid(). From their names
it is unclear whether this returns the settings or applied connection.
The (few) callers should figure that out themselves.
- rename nm_active_connection_get_id() to
nm_active_connection_get_settings_connection_id(). This function
is only used internally for logging.
- dispatcher calls now get two connections as well. The
applied-connection is used for the connection data, while
the settings-connection is used for the connection path.
- needs special handling for properties that apply immediately
when changed (nm_device_reapply_settings_immediately()).
Co-Authored-By: Thomas Haller <thaller@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=724041
The logging macros _LOGD(), etc. are specific to each
file as they format the message according to their context.
Still, they were cumbersome to define and their implementation
was repeated over and over (slightly different at times).
Move the declaration of these macros to "nm-logging.h".
The source file now only needs to define _NMLOG(), and either
_NMLOG_ENABLED() or _NMLOG_DOMAIN.
This reduces code duplication and encourages a common implementation
and usage of these macros.
Move D-Bus export/unexport handling into NMExportedObject and remove
type-specific export/get_path methods (export paths are now specified
at the class level, and NMExportedObject handles the counters for all
exported types automatically).
Since all exportable objects now use the same get_path() method, we
can also add some helper methods to simplify get_property()
implementations for object-path and object-path-array properties.
Add NMExportedObject, make it the base class of all D-Bus-exported
types, and move the nm-properties-changed-signal logic into it. (Also,
make NMSettings use the same properties-changed code as everything
else, which it was not previously doing, presumably for historical
reasons).
(This is mostly just shuffling code around at this point, but
NMExportedObject will be more important in the gdbus port, since
gdbus-codegen doesn't do a very good job of supporting objects that
export multiple interfaces [as each NMDevice subclass does, for
example], so we will need more glue/helper code in NMExportedObject
then.)
Rather than randomly including one or more of <glib.h>,
<glib-object.h>, and <gio/gio.h> everywhere (and forgetting to include
"nm-glib-compat.h" most of the time), rename nm-glib-compat.h to
nm-glib.h, include <gio/gio.h> from there, and then change all .c
files in NM to include "nm-glib.h" rather than including the glib
headers directly.
(Public headers files still have to include the real glib headers,
since nm-glib.h isn't installed...)
Also, remove glib includes from header files that are already
including a base object header file (which must itself already include
the glib headers).
config.h should be included from every .c file, and it should be
included before any other include. Fix that.
(As a side effect of how I did this, this also changes us to
consistently use "config.h" rather than <config.h>. To the extent that
it matters [which is not much], quotes are more correct anyway, since
we're talking about a file in our own build tree, not a system
include.)
This will provide an extremely easy way for applications to find out
what type of connection the system is currently using. They might want
to do this to avoid using data if a phone is on a 3G connection, for
example.
Having this as a separate property provides at least two advantages:
1) it reduces code complexity for those wanting only this one simple
piece of information
2) we could allow access to this property (but nothing else) to
privilege-separated applications in the future
This patch adds the missing nm_active_connection_get_connection_type()
which was in the header file but never actually implemented.
https://bugzilla.gnome.org/show_bug.cgi?id=739080
NMActiveConnections start out in state "unknown", but then quickly
switch to "activating". Unfortunately, it's sometimes possible for
this to be externally visible. Fix this by lying and saying that state
is "activating" during the initial "unknown" stage (though not if the
state changes to "unknown" later on).
(Actually changing the initial state to "activating" breaks things
because some code depends on there being a transition into the
"activating" state.)
This makes NetworkManager independent of <polkit/polkit.h>
development headers and libpolkit-gobject-1.so library.
Instead communicate directly with polkit using its DBUS
interface.
PolicyKit support is now always compiled in. You can control
polkit authorization with the configuration option
[main]
auth-polkit=yes|no
If the configure option is omitted, a build time default
value is used. This default value can be set with the
configure option --enable-polkit.
This commit adds a new class NMAuthManager that reimplements the
relevant DBUS client parts. It takes source code from the polkit
library.
https://bugzilla.gnome.org/show_bug.cgi?id=734146
Signed-off-by: Thomas Haller <thaller@redhat.com>
"NetworkManager.h"'s name (and non-standard capitalization) suggest
that it's some sort of high-level super-important header, but it's
really just low-level D-Bus stuff. Rename it to "nm-dbus-interface.h"
and likewise "NetworkManagerVPN.h" to "nm-vpn-dbus-interface.h"
Clean up some of the cross-includes between headers (which made it so
that, eg, if you included NetworkManagerUtils.h in a test program, you
would need to build the test with -I$(top_srcdir)/src/platform, and if
you included nm-device.h you'd need $(POLKIT_CFLAGS)) by moving all
GObject struct definitions for src/ and src/settings/ into nm-types.h
(which already existed to solve the NMDevice/NMActRequest circular
references).
Update various .c files to explicitly include the headers they used to
get implicitly, and remove some now-unnecessary -I options from
Makefiles.
Since @is_default is compared using ==, we should ensure that the
boolean properties are always either TRUE or FALSE.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Remove all remaining GParamSpec name and blurb strings (and fix
indentation while we're there), and add G_PARAM_STATIC_STRINGS to all
paramspecs that were lacking it.
Add a parameter to nm_device_add_pending_action() to silently
accept adding duplicate actions.
Same for nm_device_remove_pending_action(), to silently ignore
removing non-pending actions.
Signed-off-by: Thomas Haller <thaller@redhat.com>
When a new activation request comes in and the device is already
activated, two NMActRequests will exist for the device in parallel.
The old one handles de-activation of the device and is then disposed,
while the new one waits until the device is de-activated and then
takes over and starts the new activation.
Both requests are watching device state, and the new request may
mis-interpret the de-activation states and clean up its device pointer,
leading to assertion failures when the new activation starts.
To fix this (and because NMVPNConnection *does* always want to see
de-activation events from the device) remove the code that tries to
ignore de-activation from NMActiveConnection's device state handler.
Instead, have NMActRequest skip any reaction to device state changes
unless it is the current activation request on the device. The VPN
code always wants to see the device's state, so it doesn't need this
check.
If we are assuming a connection at startup, the NMManager:startup
state doesn't need to wait for that activation to complete, since the
underlying device isn't going to change its configuration as a result
of it.
(In particular, NM considers virbr0 to be stalled at
NM_DEVICE_STATE_IP_CONFIG when it assumes it, since if it has no real
slaves, it won't yet have carrier. But this shouldn't block startup.)
NMActiveConnection was categorizing all deactivation of master
connections as "failure", and NMActRequest was deactivating all of the
master's slaves with REASON_DEPENDENCY_FAILED no matter what the real
reason was.
In fact, NMActiveConnection only needs to handle the cases where the
master fails before enslaving the device; any failure after that point
will be caught by existing master/slave checks in NMDevice. So update
the code accordingly (and remove the master_failed code from
NMVpnConnection entirely, since no master supports having VPN slaves).
Add IP and DHCP config properties to the D-Bus ActiveConnection
objects.
For device connections, this is redundant with the properties already
on the Device object, but for VPN connections, this information was
not previously available.
When a new activation request is received, NetworkManager creates a new
NMActiveConnection to track that request. The device may already be activated,
in which case NetworkManager stops the old activation and starts the new one,
but both exist in parallel for a short period of time. If the old
NMActiveConnection is activating and already has a pending 'activation'
action, when the new NMActiveConnection adds its own 'activating' action,
they will clash. This is fixed by making each NMActiveConnection's activation
pending action uniquely named.
This fixes a g_warning with the following back trace:
#0 0x000000328224edfd in g_logv () from /lib64/libglib-2.0.so.0
#1 0x000000328224efe2 in g_log () from /lib64/libglib-2.0.so.0
#2 0x000000328224f2e6 in g_warn_message () from /lib64/libglib-2.0.so.0
#3 0x0000000000440aee in nm_device_add_pending_action (device=0x14002e0, action=0x50704a "activation") at devices/nm-device.c:7172
#4 0x000000000047525c in nm_active_connection_set_device (self=0x141b3c0, device=0x14002e0) at nm-active-connection.c:364
#5 0x0000000000475ec1 in set_property (object=0x141b3c0, prop_id=11, value=0x7fff7ff36c20, pspec=0x1405f70) at nm-active-connection.c:647
#6 0x0000003282615d3e in g_object_newv () from /lib64/libgobject-2.0.so.0
#7 0x00000032826162e6 in g_object_new_valist () from /lib64/libgobject-2.0.so.0
#8 0x0000003282616654 in g_object_new () from /lib64/libgobject-2.0.so.0
#9 0x0000000000474193 in nm_act_request_new (connection=0x13bb0e0, specific_object=0x0, subject=0x1447740, device=0x14002e0) at nm-activation-request.c:376
#10 0x000000000048e477 in _new_active_connection (self=0x13e8060, connection=0x13bb0e0, specific_object=0x0, device=0x14002e0, subject=0x1447740, error=0x7fff7ff36f90) at nm-manager.c:2947
#11 0x000000000048ed77 in impl_manager_activate_connection (self=0x13e8060, connection_path=0x134d590 "/org/freedesktop/NetworkManager/Settings/9", device_path=0x134d550 "/org/freedesktop/NetworkManager/Devices/1",
specific_object_path=0x0, context=0x143a9b0) at nm-manager.c:3206
#12 0x00000000004876c8 in dbus_glib_marshal_nm_manager_VOID__BOXED_BOXED_BOXED_POINTER (closure=0x7fff7ff37220, return_value=0x0, n_param_values=5, param_values=0x1448830, invocation_hint=0x0,
marshal_data=0x48e9dd <impl_manager_activate_connection>) at nm-manager-glue.h:189
#13 0x0000003284a0d6a9 in object_registration_message () from /lib64/libdbus-glib-1.so.2
#14 0x000000348ea1ce66 in _dbus_object_tree_dispatch_and_unlock () from /lib64/libdbus-1.so.3
#15 0x000000348ea0fa31 in dbus_connection_dispatch () from /lib64/libdbus-1.so.3
#16 0x0000003284a0acc5 in message_queue_dispatch () from /lib64/libdbus-glib-1.so.2
#17 0x0000003282247df6 in g_main_context_dispatch () from /lib64/libglib-2.0.so.0
#18 0x0000003282248148 in g_main_context_iterate.isra.22 () from /lib64/libglib-2.0.so.0
#19 0x000000328224854a in g_main_loop_run () from /lib64/libglib-2.0.so.0
#20 0x000000000042c6c0 in main (argc=1, argv=0x7fff7ff379b8) at main.c:629
Signed-off-by: Thomas Haller <thaller@redhat.com>
The NMActiveConnection class tracks the full activation request, and internal
activation requests go through the same process as external ones, including
some authentication. Sometimes that means activation is scheduled, control
returns to the mainloop, and then the activation proceeds from an idle
handler.
Unfortunately, that means that adding a pending "activation" action from
nm-device.c doesn't always work, since there is a short window between when
the activation is started in nm-manager.c (in nm_manager_activate_connection())
and when the device actually changes state. Inside that window, the pending
actions may drop to zero, and startup will be declared complete before the
device actually starts activating.
Instead, ensure that the pending action is added when the internal activation
is actually started (eg, when NMActiveConnection receives the NMDevice object).
Rather than explicitly passing around a UID and a flag saying whether
or not it's relevant.
(This also fixes a bug where the wrong UID was being recorded in
nm-settings-connection.c::auth_start(), which caused problems such as
agent-owned secrets not getting saved because of a perceived UID
mismatch.)
Various code during the activation paths will want to know whether
the connection is assumed or not, so that it doesn't do stuff that
touches the device.
The device may not be created yet (in the case of software devices)
when the ActiveConnection is created; in that case we still want to
proceed with authorization for the connection, but we'll create the
device when authorization is complete.
Both NMActRequest and NMVPNConnection need to track their device's state,
so instead of both subclasses having to do so, consolidate that code into
the superclass.
Add a 'master-ready' property to NMActiveConnection that NMDevice can
watch for to indicate that the master connection/device is ready to accept
slaves. Since the slave device's ActiveConnection is already tracking
its master connection, and since ActiveConnections don't enter the
ACTIVATING state until their device is ready for slaves, it's pretty
trivial to implement this property.
We need to track the master active connection, since it may require authentication
or other operations to complete before the device actually starts activating.
We want to create the object earlier now, and figuring out the master is
a lot of code that we don't want to run before creating the object. The
master still must be set before exporting the object over D-Bus though,
as before.
