With GCC 5, -Wlogical-not-parentheses is enabled by -Wall and warns
about suspicious code like:
int a;
...
if (!a > 1) { ... }
Fix the following warning:
test_all.c: In function ‘test_is_static’:
test_all.c:114:32: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
ASSERT (!is_static_ip6 ("eth0") == TRUE, "is static",
^
(cherry picked from commit fe765d30da)
There are three configuration options that contain device specs:
'main.ignore-carrier', 'main.no-auto-default', and
'keyfile.unmanaged-devices'.
Unify the parsing of them by splitting the device spec with
nm_match_spec_split(). This changes behavior for parsing of these
properties.
Also get rid of logging warnings when parsing 'keyfile.unmanaged-devices'.
(cherry picked from commit c6778ad1b7)
Before, when having a test with nmtst_init_assert_logging(),
the caller was expected to setup logging separately according
to the log level that the test asserts against.
Since 5e74891b58, the logging
level can be reset via NMTST_DEBUG also for tests that
assert logging. In this case, it would be useful, if the test
would not overwrite the logging level that is set externally
via NMTST_DEBUG.
Instead, let the test pass the logging configuration to
nmtst_init_assert_logging(), and nmtst will setup logging
-- either according to NMTST_DEBUG or as passed in.
This way, setting the log level works also for no-expect-message
tests:
NMTST_DEBUG="debug,no-expect-message,log-level=TRACE" $TEST
(cherry picked from commit b6d3b98655)
libnm-core treated the UNKNOWN WEP key type as KEY. Relax that
and try to guess the correct type based on the key.
This is for example important if you have a valid connection with
wep-key-type=0 (unknown)
If you request passwords for such a connection, the user cannot
enter them in password format -- but there is no UI indication
that the password must be KEY.
(cherry picked from commit 628f47285d)
==10501== 353 (32 direct, 321 indirect) bytes in 1 blocks are definitely lost in loss record 1,579 of 1,641
==10501== at 0x7EE3728: g_type_create_instance (gtype.c:1847)
==10501== by 0x7EC75B4: g_object_new_internal (gobject.c:1746)
==10501== by 0x7EC945C: g_object_newv (gobject.c:1890)
==10501== by 0x7EC9C23: g_object_new (gobject.c:1556)
==10501== by 0x1CD87C: nm_setting_wireless_security_new (nm-setting-wireless-security.c:122)
==10501== by 0x16F70B: make_wpa_setting (reader.c:3010)
==10501== by 0x16F33F: make_wireless_security_setting (reader.c:3188)
==10501== by 0x161F4C: wireless_connection_from_ifcfg (reader.c:3464)
==10501== by 0x16109A: connection_from_file_full (reader.c:4763)
==10501== by 0x1614EE: connection_from_file_test (reader.c:4862)
==10501== by 0x13D1D6: test_read_wifi_wpa_psk_unquoted2 (test-ifcfg-rh.c:4316)
==10501== by 0x1281FD: main (test-ifcfg-rh.c:12513)
==10501==
(cherry picked from commit fcfd8f487a)
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)
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)
Custom IP ranges for shared connection were implemeted in bgo #6759732
(commit 32a001f526). The first IP address
is used and a range is calculated.
However, the commit missed to update ifcfg-rh plugin to read the address.
Test case:
* use ifcfg-rh plugin for NetworkManager
$ nmcli con add type eth con-name shared-ip ifname eth0
$ nmcli con mod shared-ip ipv4.addresses 9.8.7.6/24 ipv4.method shared
$ nmcli con show shared-ip
$ nmcli con show shared-ip <--- ip address 9.8.7.6 was missing
https://bugzilla.redhat.com/show_bug.cgi?id=1174632
(cherry picked from commit c8fe3bbabc)
If a connection has an associated "rule-NAME" or "rule6-NAME" file,
don't try to read in the routes, since NetworkManager won't be able to
parse them correctly. Instead, log a warning that they will need to be
applied via a dispatcher script, and provide a script that would do
that in examples/dispatcher/.
(cherry picked from commit f79d62692e)
Add a "filename" property to NMSettingsConnection, and set it from
keyfile and ifcfg-rh (replacing the existing priv->path variables in
those connection types). (The other plugins either don't use files, or
don't use per-connection files.)
(cherry picked from commits 24a464a7da
and c9002c041d)
