Otherwise, we might still be called back with D-Bus requests, after
the NMVpnServicePlugin instance is already destroyed.
(cherry picked from commit 929f36c56f)
The asynchronous secret agent initialization doesn't work at all due to a
rather silly typo. Oops.
While at it, fix a whitespace error too.
(cherry picked from commit 603daa5b25)
The actions are not too useful my themselves, but it will be possible to
embed them into traffic filters in subsequent commits.
(cherry picked from commit 7c8ce778fb)
Team allows to specify multiple link watchers for each link.
Define a link watcher object in order to allow to specify multiple ones
for each Team configuration.
(cherry picked from commit 72f6d08714)
- only add an async version. I think sync requests are fundamentally flawed
because they mess up the order of D-Bus messages. Hence, also don't
call the function *_async(), like we do for other functions. As there
is only the async form, it doesn't have a suffix.
- Don't accept a NMConnection as @settings argument, but a GVariant.
In general, keep the libnm API closer to the D-Bus API and don't hide
the underlying function with a less powerful form. The user still can
conveniently call the function with
nm_remote_connection_update2 (connection,
nm_connection_to_dbus (NM_CONNECTION (connection),
NM_CONNECTION_SERIALIZE_ALL),
save_to_disk
? NM_SETTINGS_UPDATE2_FLAG_TO_DISK
: NM_SETTINGS_UPDATE2_FLAG_IN_MEMORY,
NULL,
cancellable,
callback,
user_data);
I believe the parts of libnm that invoke D-Bus methods, should be
close to the D-Bus API. Not like nm_remote_connection_commit_changes()
which has no corresponding D-Bus method.
(cherry picked from commit d00eb95c55)
We already have Update(), UpdateUnsaved() and Save(), which serve
similar purposes. We will need a form of update with another argument.
Most notably, to block autoconnect while doing the update.
Other use cases could be to prevent reapplying connection.zone and
connection.metered, to to reapply all changes.
Instead of adding a specific update function that only serves that
new use-case, add a extensible Update2() function. It can be extended
to cope with future variants of update.
(cherry picked from commit 98ee18d888)
The order of elements in array properties was inverted when
reconstructing the array. Keep the original order from D-Bus.
(cherry picked from commit c90118ff60)
The number of authentication retires is useful also for passwords aside
802-1x settings. For example, src/devices/wifi/nm-device-wifi.c also has
a retry counter and uses a hard-coded value of 3.
Move the setting, so that it can be used in general. Although it is still
not implemented for other settings.
This is an API and ABI break.
There is no API to get all settings. You can only ask for
settings explicitly, but that requires you to probe for them
and know which ones may exist.
The alternative API might be nm_connection_for_each_setting_value(),
but that only iterates over settings' properties. If a setting has no
properties, it is ignored.
We added "ipv4.route-table-sync" and "ipv6.route-table-sync" to not change
behavior for users that configured policy routing outside of NetworkManager,
for example, via a dispatcher script. Users had to explicitly opt-in
for NetworkManager to fully manage all routing tables.
These settings were awkward. Replace them with new settings "ipv4.route-table"
and "ipv6.route-table". Note that this commit breaks API/ABI on the unstable
development branch by removing recently added API.
As before, a connection will have no route-table set by default. This
has the meaning that policy-routing is not enabled and only the main table
will be fully synced. Once the user sets a table, we recognize that and
NetworkManager manages all routing tables.
The new route-table setting has other important uses: analog to
"ipv4.route-metric", it is the default that applies to all routes.
Currently it only works for static routes, not DHCP, SLAAC,
default-route, etc. That will be implemented later.
For static routes, each route still can explicitly set a table, and
overwrite the per-connection setting in "ipv4.route-table" and
"ipv6.route-table".
Currently, after a client performs a connectivity check it cannot
access the up-to-date value of the manager.connectivity property right
away, but it must wait that the queued PropertiesChanged signal is
processed, which is cumbersome.
Arguably, clients already receive the new connectivity value as the
result of the connectivity check call, so they don't have to read it
from the object; however it would be better if the right value of the
object property was available immediately as well.
https://bugzilla.gnome.org/show_bug.cgi?id=784629
Expose previously internal function nm_ip_route_equal_full(). It's
just useful API.
However, add a @cmp_flags argument, so that in the future we could
extend it.
GNOME Settings 3.26 is crashing every time a VPN connection changed its
state. After some digging, a debug message was put on dispose, and this
issue was found:
libnm-Message: Object 0x55555633c070 disposed
libnm-Message: Object 0x55555633c730 disposed
libnm-Message: Object 0x55555633eae0 disposed
libnm-Message: Object 0x555556340a80 disposed
Thread 1 "gnome-control-c" received signal SIGSEGV, Segmentation fault.
g_type_check_instance_cast (type_instance=type_instance@entry=0x55555633c070, iface_type=93825006537856) at /.../glib/gobject/gtype.c:4057
4057 node = lookup_type_node_I (type_instance->g_class->g_type);
(gdb) bt
NetworkManager is calling callbacks on disposed objects, which leads to
crashes in clients (e.g. GNOME Settings).
Fix this issue by disconnecting signal handlers when the objects are
disposed.
Patch originally by Georges Basile Stavracas Neto <georges.stavracas@gmail.com>
https://bugzilla.gnome.org/show_bug.cgi?id=787893
If no setting name is found in the file, it means that the file
possibly contains a setting superclass (e.g. NMSettingIPConfig)
without any property definition; just ignore it.
