Since commit 0922a17738 ("manager: avoid that auto-activations
preempt user activations") the manager doesn't allow a internal
activation to disconnect the same connection already active on the
device. Thus, during a rollback we must ensure that the device is
deactivated before.
Fixes: 0922a17738
(cherry picked from commit 348959cfa2)
Revert the change to initialize the GDBusObjectManager
synchronously. I still maintain that GDBusObjectManager's
async initialization is severely broken on it's own, but this
change broke
$ systemctl restart NetworkManager
$ nmcli connection up "$NAME"
leaving nmcli hanging, as libnm fails to process some D-Bus signals.
I think that hints to another bug, but apparently the previous
version was less broken. So revert for now.
https://bugzilla.redhat.com/show_bug.cgi?id=1450075
(cherry picked from commit 95ff2b8e8a)
Strangely, this breaks
systemctl restart NetworkManager
nmcli connection up "$NAME"
It seems that with this change, libnm misses some events from D-Bus.
It looks like there is something seriously broken. Before fixing it,
revert the previous state.
https://bugzilla.redhat.com/show_bug.cgi?id=1450075
This reverts commit 529d620a59.
(cherry picked from commit 45d6147098)
The default value for miimon, when missing in the setting, is 0 if
arp_interval is != 0, and 100 otherwise. So, when generating a
connection, let's ignore miimon=0 (which means that miimon is
disabled) and accept any other value. Adding miimon=100 does not cause
any harm to the connection assumption.
While at it, slightly improve the code: ignore_if_zero() is not useful
for 'updelay','downdelay','arp_interval' because zero is their default
value, so introduce a new function that checks if the value is the
default (and specially handles 'miimon').
Reported-by: Taketo Kabe <rkabe@vega.pgw.jp>
https://bugzilla.redhat.com/show_bug.cgi?id=1463077
(cherry picked from commit 92fc109183)
When a user forces up a connection on a device, mark earlier the
device as managed: this would allow proper clean-up on the device also
when it was previously unmanaged or assumed.
This would avoid skipping IPv6LL address generation when instead it was
needed.
Fixes: adbf383628https://bugzilla.redhat.com/show_bug.cgi?id=1452046
(cherry picked from commit d4a033c4ad)
These properties are internal and shall not be publicly accessible.
Remove the getter.
We may later no longer use GDBusObjectManager. It should be an implementation
detail, not exposed in the public API of NMObject.
(cherry picked from commit 357fd6ba82)
The current implementation of GDBusObjectManagerClient implements
GAsyncInitableIface, however it simply runs GInitableIface's
synchronous init on another thread.
I suspect that there are races in the way that is implemented.
For one, we see crashes and warnings (rh#1450075, rh#1457769,
rh#1457223). Also, it seems very wrong to me, how GDBusObjectManagerClient
mixes asynchronous signals (on_control_proxy_g_signal) with
synchronously getting all objects (process_get_all_result,
GetManagedObjects).
I think we should ditch GDBusObjectManager altogether, including the
gdbus-codegen skeletons. They add layers of code, for something that
should be simple to do directly. For now, just don't do asynchronous
initialization on another thread, so we at least avoid this kind of
multithreadding issue.
This may make the initialization of NMClient a bit slower.
(cherry picked from commit 529d620a59)
Cancelling an operation shall not mean to not invoke the result callback.
The result callback is *always* to be invoked.
(cherry picked from commit c5a48b7a0b)
In _internal_activate_device(), we try to find an existing master AC
for the slave AC, and we create a new one in case of failure. The
master AC may already exist, but it may not be detected by
find_master() because it is undergoing authorization.
The result is that we auto-activate the master when there is already a
user activation in place, and the auto-activation will cancel the user
one. This is bad, as user-activation should always have precedence.
To fix this, introduce a last-minute check before activating internal
connections.
https://bugzilla.redhat.com/show_bug.cgi?id=1450219
(cherry picked from commit 0922a17738)
No need to clone the list anymore. Unfortunately, GPtrArray is not NULL
terminated (without extra effort), so we have to pass on the GPtrArray
instance for the length.
(cherry picked from commit 19a98c6f61)
A negative ipv4.dns-priority and ipv6.dns-priority has the meaning to configure
the DNS information of the connection exclusively. With systemd-resolved, that means
we must explicitly unset the configuration from other interfaces.
https://bugzilla.gnome.org/show_bug.cgi?id=783569
(cherry picked from commit 70792e51d9)
The code was correct previously, but it was confusing to me,
because
- once @skip gets set to TRUE, it stays TRUE for the rest
of the loop.
- in each additional skipped iteration, it would still set
plugin_confs[i] to NULL. Which is not wrong, but confusing.
- it would set "prev_prio = prio;" in each iteration.
After @skip is set to TRUE, that doesn't matter anymore,
but is confusing. Before @skip is set to TRUE it also
doesn't really matter to set it more then once, because
we only care about the very first priority.
- @skip sounded to me like the current iteration would
be skipped. But really all remaining will be skipped too.
(cherry picked from commit aa347182bb)
For externally managed interfaces, we create an in-memory connection
and keep the device with sys-iface-state=external.
When the user actively modifies the connection, we persist it to
storage. But we also must take over managing the device.
One problem is that nm_device_reapply() errors out if the device
is still activating. It's unclear how to reapply the connection
while the device is in the process of activation. So, if the user
modifies the created connection very quickly, reapplying the settings
will fail.
https://bugzilla.redhat.com/show_bug.cgi?id=1462223
(cherry picked from commit 10c0632df0)
We react on changes to NMSettingsConnection.flags, so that we can update
from an external activation to a managed one.
However, previously we would only register the _settings_connection_notify_flags
callback during _set_settings_connection(). So, if via constructor properties
we first set PROP_SETTINGS_CONNECTION and later PROP_ACTIVATION_TYPE, we wouldn't
register the callback.
(cherry picked from commit b84da25713)
The INT signal can arrive after a new line has been processed in
nmc_readline_helper(). In such case, the handler gets uninstalled by
readline_cb() and nmc_seen_sigint() returns TRUE. However it's an
error to call rl_callback_read_char() without handler, don't do it.
Fixes the following:
"readline: readline_callback_read_char() called with no handler!"
#0 __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 __GI_abort () at abort.c:90
#2 rl_callback_read_char () at ../callback.c:116
#3 nmc_readline_helper (prompt=prompt@entry=0x2aa0d229080 "nmcli> ") at clients/cli/common.c:1387
#4 nmc_readline (prompt_fmt=prompt_fmt@entry=0x2aa0036ac9e "%s") at clients/cli/common.c:1448
#5 do_connection_edit (connection=0x2aa0d215440, nmc=0x2aa00391298 <nm_cli>) at clients/cli/connections.c:7072
Fixes: 995229181chttps://bugzilla.redhat.com/show_bug.cgi?id=1458311
(cherry picked from commit cd3a561251)
When IPv4 addresses are synchronized to platform, the order of IPv4
addresses matters because the first address is considered the primary
one. Thus, nm_ip4_config_capture() should put the primary address as
first, otherwise during synchronization addresses will be removed and
added back with a different primary/secondary role.
https://bugzilla.redhat.com/show_bug.cgi?id=1459813
(cherry picked from commit b6fa87a4c0)
Since commit 2b51d3967 "device: merge branch 'th/device-mtu-bgo777251'",
we always set the MTU for certain device types during activation. Even
if the MTU is neither specified via the connection nor other means, like
DHCP.
Revert that change. On activation, if nothing explicitly configures the
MTU, leave it unchanged. This is like what we do with ethernet's
cloned-mac-address, which has a default value "preserve".
So, as last resort the default value for MTU is now 0 (don't change),
instead of depending on the device type.
Note that you also can override the default value in global
configuration via NetworkManager.conf.
This behavior makes sense, because whenever NM actively resets the MTU,
it remembers the previous value and restores it when deactivating
the connection. That wasn't implemented before 2b51d3967, and the
MTU would depend on which connection was previously active. That
is no longer an issue as the MTU gets reset when deactivating.
https://bugzilla.redhat.com/show_bug.cgi?id=1460760
(cherry picked from commit 4ca3002b86)
When running one of:
nmcli device wifi list ifname wlan0
nmcli device wifi connect ... ifname wlan0
nmcli wrongly adds the device name to the output.
Do the completion only when requested.
Fixes: 8679793f6b
Fixes: 1a0dfd31c4
(cherry picked from commit d2b4332b36)
- don't use assert but be more graceful with g_return_if_fail().
- in case of failure, don't log a debug message after the warning.
One message is sufficient, drop "pppd pid %d cleaned up".
- print GPid type as long long.
- increase log level to warning. pppd dying unexpectedly warrants a
warning.
(cherry picked from commit 250e723951)
ppp_exit_code() does too much or too little. Either it should log
about all reasons why pppd exited, including signals, or it should
just do the status to string conversion. Split it.
(cherry picked from commit 3f64910b52)
Let's explicitly unexports on dispose(). Probably that already
happened, because NMExportedObject asserts that it is unexported
during !quitting.
During quitting, we probably don't tear down the manager.
Anyway, we should always unexport.
(cherry picked from commit f07dca941d)
