This was not really an error, because NMIfcfgConnection would not
watch the files if monitoring is not enabled. Still do it, because
it feels more correct.
(cherry picked from commit 236226a590)
Make update_connection() analogous to keyfiles implementation.
Effectively merge _internal_new_connection() and update_connection()
-- previously connection_new_or_changed().
https://bugzilla.redhat.com/show_bug.cgi?id=1171751
(cherry picked from commit 0c6349c627)
Presort the files in read_connections() as we do it
for keyfile.
This alone has not much consequences. Do this patch first, to
keep the next patches more self-contained.
(cherry picked from commit 0cf00ff3aa)
The ifcfg-rh implementation should be similar to the one from keyfile.
Rename the variables and function that have the same meaning.
Do this trivial commit first, before starting refactoring.
(cherry picked from commit a609dd12d3)
When adding a connection to NMSettings we did not check for
duplicate connection UUIDs (which could for example happen
if two different plugins report a conflicting UUID).
Also, we would not check that an already added connection
changes it's UUID.
Both could lead to have duplicate connections (by UUID).
Avoid that two ways:
- when adding a connection to NMSettings, ensure that we don't add
a conflicting UUID. Otherwise just bail out and do nothing.
- when modifying a connection that is already added to NMSettings,
enforce that the UUID cannot change. Otherwise fail with error.
For ifcfg-rh plugin this situation still can happen during reload.
In this case error out and refuse to update the connection. After
all, the user configured invalid UUIDs.
https://bugzilla.redhat.com/show_bug.cgi?id=1171751
(cherry picked from commit 7b807b11cc)
When writing a file (for example with `sed -i`) a temporary file
might be created and removed quickly. This causes spurious events
in dir_changed().
(cherry picked from commit 8ba8a55cfa)
Also during add_connection() we must take special care of not "adding" a
connection with a conflicting UUID. In that case we want to fallback to
"update".
update_connection() already does all the checks, so call
update_connection() from add_connection().
(cherry picked from commit db5c4ce64f)
Log lines with a "keyfile:" prefix and show more information about
the loaded connection. Especially printing the UUID is interesting.
(cherry picked from commit 5c2fa92099)
If there are keyfiles with duplicate UUIDs, read_connections()
would iterate over the files, loading them as they appear and
overwriting duplicate connections that were just loaded.
For example, have keyfiles 'A' and 'B' with the same UUID.
On start, NM might first load 'A', then 'B'. 'B' would replace the
content of 'A' which was just loaded.
On reload, NM would first overwrite 'B' with 'A', and then again
overwriting 'A' with 'B'.
Fix that by accept the first found connection and don't overwrite
it during the same read_connections() run.
Also sort the files by file modification timestamp so that we
get a reproducible and sensible behavior.
(cherry picked from commit 8a4e64c6aa)
new_connection() and update_connection() are very similar as both
must anticipate collisions of UUIDs.
When reloading a connection (update_connection(), previously), the loaded
connection for a certain path might actually replace another existing
connection. In this case, the old connection must be removed, and
the existing one updated instead.
If reloading a connection changes the UUID to a new value, the old
connection must be removed likewise and a new connection added.
Merge both functions into update_connection().
(cherry picked from commit c2fcb680f8)
Only log connection diffs when we update a connection that we actually
care about.
Note that most plugin specific connections use
nm_settings_connection_replace_settings() in their constructor
to initialize themselves. These occurrences are not interesting
and spam the logfile.
(cherry picked from commit e14ea6818a)
The statement
g_return_val_if_reached (NM_MODEM_IP_TYPE_UNKNOWN);
was wrong, because the return type is 'const char *'.
But just refactor nm_modem_ip_type_to_string() to get rid of
the static table and make it a switch statement.
Fixes: 02beeeeb12
(cherry picked from commit 5599a82d0d)
dhclient only supports fqdn.fqdn for server DDNS updates with
DHCPv6. And even though the underlying DHCP options that fqdn.fqdn
controls allow non-qualified hostnames on the wire, dhclient does
not. So we must require a fully-qualified name for DHCPv6.
Second, while no-client-updates seems like it should be "off", doing
that apparently makes dhclient set the "O" flag to 1 which appears to
be a bug, and results in the server not doing the DDNS update. So
we must stop setting that option too.
Found by: Alexander Groß
(cherry picked from commit 677cee0f23)
When ipv4=auto and ipv6=auto, we'll first try with the IPv4v6 PDP type, and if
that fails (e.g. if either the modem or the operator doesn't support it), we'll
fallback to trying with IPv4 or IPv6 PDP types (only if may-fail configuration
allows it).
Patch based on a previous implementation by Dan Williams <dcbw@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=733696
When the modem device is abruptly disconnected,
nm_modem_device_state_changed() calls deactivate_cleanup() with a NULL
device argument and that's perfectly fine.
We should only check the instance type if we know the device is non-NULL.
(NetworkManager:9166): NetworkManager-wwan-CRITICAL **: deactivate_cleanup: assertion 'NM_IS_DEVICE ( failed
(cherry picked from commit 41c87eb363)
ModemManager needs to have CLOCAL set in the TTY termios configuration, in order
to notify the kernel that modem control lines are not in effect (e.g. so that a
transition to LOW in the DCD input control line doesn't trigger a hangup in the
TTY).
pppd in the other hand, needs CLOCAL unset in order to have proper modem control
lines in effect during the PPP session. So, when pppd starts it will store the
original termios settings, and before exiting it will restore the original
settings in the TTY. In other words, if CLOCAL was set before launching pppd,
CLOCAL will be also set after pppd exits.
Now, in order for this sequence to work correctly, NetworkManager also needs to
make sure that ModemManager is notified about the disconnection only after pppd
has really finished re-configuring the TTY.
https://bugzilla.gnome.org/show_bug.cgi?id=734347
----------------------
Once the patch is applied, we will be making sure that ModemManager is only
notified about the disconnection AFTER pppd has fully exited:
NetworkManager[27589]: <info> (ttyUSB2): device state change: activated -> deactivating (reason 'user-requested') [100 110 39]
Terminating on signal 15
nm-pppd-plugin-Message: nm-ppp-plugin: (nm_phasechange): status 10 / phase 'terminate'
nm-pppd-plugin-Message: nm-ppp-plugin: (nm_phasechange): status 8 / phase 'network'
Connect time 0.3 minutes.
Sent 56 bytes, received 0 bytes.
nm-pppd-plugin-Message: nm-ppp-plugin: (nm_phasechange): status 5 / phase 'establish'
nm-pppd-plugin-Message: nm-ppp-plugin: (nm_phasechange): status 11 / phase 'disconnect'
Connection terminated.
nm-pppd-plugin-Message: nm-ppp-plugin: (nm_phasechange): status 1 / phase 'dead'
nm-pppd-plugin-Message: nm-ppp-plugin: (nm_exit_notify): cleaning up
NetworkManager[27589]: <warn> pppd pid 27617 exited with error: pppd received a signal
NetworkManager[27589]: <info> (ttyUSB2): modem state changed, 'connected' --> 'disconnecting' (reason: user-requested)
NetworkManager[27589]: <info> (ttyUSB2): modem state changed, 'disconnecting' --> 'registered' (reason: user-requested)
NetworkManager[27589]: <info> (ttyUSB2) modem deactivation finished
NetworkManager[27589]: <info> (ttyUSB2): device state change: deactivating -> disconnected (reason 'user-requested') [110 30 39]
NetworkManager[27589]: <info> (ttyUSB2): deactivating device (reason 'user-requested') [39]
(cherry picked from commit fe090c34b7)
This method doesn't prevent the original logic in which the child process was
stopped when the last reference of the PPP manager was unref-ed.
(cherry picked from commit 14f732e8df)
This method isn't run if NM is quitting; so the deactivate() method still needs
to be implemented to handle sync disconnection requests.
(cherry picked from commit f3efdbcdf2)
It's always user requested -- auto activation never happens on already active
devices. nm_device_release_one_slave() rightly asserts teardown with
(un)configuration does not happen for no reason at all.
https://bugzilla.gnome.org/show_bug.cgi?id=744812
(cherry picked from commit 600489003f)
It was confusing to understand the difference between calling nm_device_connection_is_available()
and check_connection_available(), they behaved similar, but not really
the same. Especially nm_device_connection_is_available() would look
first into @available_connetions, and might call check_connection_available()
itself. Whereas @available_connetions was also populated by testing
check_connection_available(). This interrelation makes it hard to
understand when nm_device_connection_is_available() returned true.
Rename nm_device_connection_is_available() to nm_device_check_connection_available()
and remove all direct calls of check_connection_available() in favor of
the wrapper nm_device_check_connection_available().
Now we only call nm_device_check_connection_available() with different
parameters (@flags and @specific_object). We also have the additional
guarantee that specifying more @flags will widen the result and making
a connection "more" available, while specifying a @specific_object will
restrict it.
This also changes behavior in several cases. For example before
nm_device_connection_is_available() for user-requests would always
declare matching connections available on Wi-Fi devices (only)
regardless of the device state. Now the device state gets consistently
considered.
For default-unmanaged devices it also changes behavior in complicated
ways, because before we would put connections into @available_connetions
for every device-state, but nm_device_connection_is_available() had a
special over-ride only for unmanaged-state.
This also fixes a bug, that user can activate an unavailable Wi-Fi
device:
nmcli radio wifi off
nmcli connection up wlan0
(cherry picked from commit d80f1bf4f0)
Having logging statements in a simple getter (or is_*()) means
you cannot call these functions without cluttering the log.
Another approach would be to add an @out_reason argument, and
callers who actually care log the reason. For now, just get rid
of the messages.
(cherry picked from commit e524be2c34)
The argument name should express what the caller wants
(he wants to know, whether the connection can be activated
for an internal or external activation request).
Whether that involves checking device-specific overrides, is
not the point -- nm_device_check_connection_compatible() is
also a virtual function with device-specific overrides.
(cherry picked from commit a7e0a038bf)
The queued activation request must transition state to
DEACTIVATED, otherwise it is not removed from the list
of active_connections in NMManager.
(cherry picked from commit b9da094da9)
After refactoring libnm-core to use GBytes instead of
GByteArray/DBUS_TYPE_G_UCHAR_ARRAY, it was forgotten to update
keyfile writer.
This causes keyfile writer to skip the NMSetting8021x:password-raw setting
and raise a g_critical() warning.
Fixes: c43f88907b
(cherry picked from commit c651b27793)
