As we don't take a reference on @self during the asynchronous
request, we must properly support cancelling in case of early
destruction.
I think, it's gdbus' responsibility not to leak any file descriptors
when cancelling a D-Bus request that returns file descriptors. Thus,
our usual pattern works here too.
(cherry picked from commit 2e3ff56cdc)
$ nmcli connection up my-connection
Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/42)
$ nmcli connection modify my-connection connection.id other-name
$ nmcli -f connection.id connection show other-name
connection.id: other-name
$ nmcli -f GENERAL.CONNECTION device show enp0s25
GENERAL.CONNECTION: my-connection
$ nmcli connection down other-name
Error: 'other-name' is not an active connection.
Error: no active connection provided.
$ nmcli connection down my-connection
Connection 'my-connection' successfully deactivated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/13)
When modifying a connection, NMActiveConnection must update the D-Bus
properties that belong to the settings-connection.
(cherry picked from commit 18019d55a1)
This is mostly interesting of NMPolicy, which no longer needs to
subscribe to two almost identical signals (where the by-user signal
was always invoked together with the plain "updated" signal).
(cherry picked from commit 3164c026a2)
Instead of connecting to two similar signals, combine them into one
and pass "by_user" argument.
We still need to keep the original NM_SETTINGS_CONNECTION_UPDATED signal,
because it is exposed on D-Bus.
(cherry picked from commit 65c55e2a78)
I want to combine NM_SETTINGS_CONNECTION_UPDATED and NM_SETTINGS_CONNECTION_UPDATED_BY_USER
into one signal. Thus, they must have same behavior with respect as to whether they are
scheduled on idle.
Emit NM_SETTINGS_CONNECTION_UPDATED right away.
The "Updated" signal is exposed via D-Bus on the settings object.
Removing the idle handling has no bad consequences there.
Apart from that, the signal has only the listener NMSettings::connection_updated().
connection_updated() first emits NM_SETTINGS_SIGNAL_CONNECTION_UPDATED, which only
has listener: NMPolicy::connection_updated(), which already delegates to
an idle handler.
Second, NMSettings::connection_updated() emits
NM_CP_SIGNAL_CONNECTION_UPDATED which has the following listeners:
- NMBluezDevice::cp_connection_updated(), which can cause the
connection to be tracked/untracked. Any further changes are
already delayed on an idle handler (check_emit_usable_schedule()).
- NMDevice::cp_connection_added_or_updated(), which causes the
connection to be tracked by the device. It also emits
"notify::available-connections", which however is only relevant
for the D-Bus bindings.
At last, it does available_connections_check_delete_unrealized()
which also is on an idle handler already.
(cherry picked from commit a4f1a1794f)
Currently, NM_CP_SIGNAL_CONNECTION_UPDATED signal will be invoked on an
idle handler. I want to change that, so to be save, delay actions that
matter on an idle handler.
(cherry picked from commit 640ef67cd7)
schedule_activate_all() needs to iterate over all devices and is thus
relatively costly (and scales O(n^2)).
By scheduling the action on an idle handler we delay and combine
multiple redundant requests.
Another reason is that NM_SETTINGS_CONNECTION_UPDATED is currently
executed on an idle handler which first leads to
NM_SETTINGS_SIGNAL_CONNECTION_UPDATED signal and eventually calls
schedule_activate_all().
I want to change that to emit the connection update signal immediately,
thus to preserve the delay, we delay handling in NMPolicy.
(cherry picked from commit 920054d8aa)
Due to a bug, NMManager would connect to "notify::connections"
and might miss an important notification when NMSettings declares
startup-complete.
Fixes: b067ca7034
(cherry picked from commit c57e5a6b66)
When one of the configuration snippet is malformed, NM doesn't tell
which file caused the error:
$ NetworkManager --print-config
Failed to read configuration: Key file does not start with a group
Fix this.
$ NetworkManager --print-config
Failed to read configuration: /usr/lib/NetworkManager/conf.d/test.conf: Key file does not start with a group
(cherry picked from commit 57c001200d)
As explained in the function comment, a NULL value for @val is
acceptable. Otherwise:
$ nmcli connection edit
(process:2276): nmcli-CRITICAL **: check_valid_name: assertion 'val' failed
Fixes: fb8fe1d8cb
(cherry picked from commit 73221a809d)
VPN plugins are often not installed or they might be legacy-only.
In both cases we should show a better error message about the
failure reason.
(cherry picked from commit d0f01aa2c2)
Instead of using (only) a hard-coded list of VPN types,
prefer lookup the VPN settings from the .name files.
Still, fallback to a hard-coded list if the plugin cannot
be found, because for connection-add we currently don't
actually need the plugin installed.
(cherry picked from commit 41976e3069)
Otherwise building fails with:
nm-sleep-monitor-upower.c:132:45: error: expected declaration specifiers or '...' before 'nm_sleep_monitor_get'
nm-sleep-monitor-upower.c:132:67: error: expected declaration specifiers or '...' before '(' token
https://mail.gnome.org/archives/networkmanager-list/2016-May/msg00053.html
In general we don't touch the externally set default route on devices
that use a generated-assumed connection. When the IP method is AUTO
(or DHCP), this means that we are not able to restore the default
route after a temporary expiration of the lease which removes
addresses/routes from the device.
Change this, and let NM update the default route for generated-assumed
devices using dynamic addressing.
https://bugzilla.redhat.com/show_bug.cgi?id=1265239
(cherry picked from commit 9b7f9af077)
The applied connection must describe the configuration that was
initially activated on the device. Even if the IP configuration
changes, we shouldn't reset the applied connection for devices using a
generated-assumed connection, otherwise we would lose information on
the IP method we're trying on the device.
(cherry picked from commit c84fd50287)
No need to require the caller to initialize the optional out-argument.
Otherwise we get:
(nm-connection-editor:2471): libnm-CRITICAL **: nm_utils_file_is_private_key: assertion 'out_encrypted == NULL || *out_encrypted == FALSE' failed
https://bugzilla.gnome.org/show_bug.cgi?id=763578
Fixes: 1c4f41c610
(cherry picked from commit 81499355b0)
g_file_read_link() "reads" the symbolic link. If it's a relative path,
we get a relative path which is anchored on @file. We must resolve that
to be absolute.
(cherry picked from commit 7f7e1eb60b)
It's not enough to consider IF_LOWER_UP flag. Instead,
the important flag is actually IF_UP.
Actually, I suspect that IF_LOWER_UP is not needed. But for
now leave it, in order not to break something.
(cherry picked from commit 02e84ba1e8)
This is especially important, because changing MTU takes the
link down for a moment. Taking a link down deletes IP routes and
IPv6 addresses. Thus, when the link comes up again, we must restore
them.
Otherwise, we don't call merge_and_apply() until the next DHCP lease
(or possibly never in case of static addressing).
https://bugzilla.redhat.com/show_bug.cgi?id=1309899
(cherry picked from commit 35a7ea77b0)
nm_device_set_ip4_config() is called during cleanup and
from ip4_config_merge_and_apply(). The latter, has several
call sites.
It's not easy to track whether we called set_ip4_config with
or without commit (and if we call it without commit, we might
not see a logging line at all).
(same for nm_device_set_ip6_config()/ip6_config_merge_and_apply()).
(cherry picked from commit f50e39fc98)
