Writing a connection to keyfile and read it back should result
in the identical setting. That is, a full round-trip would not
alter any information.
That is however particularly not true for certificate properties, where
the keyfile writes blobs to file and coerces paths.
Thus, whenver writing a keyfile we must read back what we just
wrote and use that instead.
Add API to re-read the keyfile after writing it.
Usually, we would expect that whenever we serialize
something to disk, it can be read back exactly the same.
That is however not true for certificates, where we mangle
path and blobs while writing to file.
Anyway, extend the write-API to re-read what we just wrote.
The tests got extended to assert that whatever we write can
be read back the same.
Later, we want to reinject the reread connection into the settings
plugin again.
A "vlan" setting can optionally have an ethernet setting.
However, ifcfg-rh reader always adds such a setting, because
well... Anyway, the result is that writing a VLAN setting
without ethernet section will yield a different result
on re-read.
Let's have normalization add the ethernet setting, so that
two we consistently have it present.
Our reader/writer has flaws. We easily write out something that
is re-read differently. That is a problem and should be fixed.
Add API to re-read the connection after writing.
Extend the tests to check that the re-read value is identical
to what we wrote. In some cases, this does not hold. That is
usually a bug which needs fixing. Note that for certificate
blobs and paths we may intentionally mutate the connection
during writing, so there are valid cases where a connection
is re-read differently.
Avoid using new_settings when they are none. Also, don't shortcut when
the connection hasn't been changed -- let the settings plugin decide if
it needs to rewrite the connection.
Some keys, such as MASTER may still be different as they may depend on
other connections. svWriteFile() checks if the resulting file is
different already anyway.
Don't reuse NMDeviceStateReason for the autoconnect-blocked-reason. There are
only two cases we care: blocked-due-to-no-secrets, blocked-otherwise.
Encode these values in a new enum type.
Add svGetValue_cp() and svGetValueStr() for completeness.
Currently, we mostly use svGetValueStr_cp(), which I think is wrong
because for most cases we should instead not ignore empty values -- that
is, svGetValue_cp() would be a better choice.
Also, I think that the non *_cp() API should be preferred in many cases
because it avoids cloning the value in many cases. The API is not
necessarily less favorable either:
gs_free char *value = NULL;
value = svGetValue_cp (s, key);
if (value)
...
vs.
gs_free char *value_to_free = NULL;
const char *value;
value = svGetValue (s, key, &value_to_free);
if (value)
...
Add the two missing variants, so that future code can use what fits
best, not following undesired practices because seemingly there is
no alternative.
We have
- svGetValue()
- returns the original string
- avoids copying the string unless necessary
- svGetValueStr_cp() (formerly svGetValueString())
- returns the original string, unless it is empty ""
- always clones the string
I think the behavior svGetValueStr*() of coercing "" to NULL is wrongly
used in most places. We should better handle "" like any other value,
not treat it as unset.
That would require another function svGetValue_cp(), which is like svGetValue()
but always copies the string. Rename svGetValueString() so that there is a place
for names like
- svGetValue_cp()
- svGetValueStr()
Also rename svSetValueString() to svSetValueStr().
Ifcfg reader now properly handles escaping and quoting. We don't
need to stip whitespace, if somebody explicitly configures
prop=" value"
it is a configuration error.
ifnet has two extra instances @p12_type/@phase2_p12_type, that only
differed from @pk_type/@phase2_pk_type by their suffix.
But as the suffix field as unused, we can drop that entirely.
If one property has multiple ways to be handled, we should not create
two ObjectType instances, instead let the ObjectType have enough
information to act accordingly.
The PKCS#11 URIs start with the "pkcs11:" scheme. There's a slight
possiblity of a clash with file names relative to the ifcfg file, but
that's probably is unlikely enough the leave us not worried.
The alteratives are probably more horrible (using a different key, or
using a separate key for the scheme alone) and it's already simple
enough to avoid a clash by using an absolute file name.
When the main ifcfg file contains no IP addresses, the method
will be "disabled". Later, when reading IP addresses for the
aliases, we must ensure that the method is manual.
Otherwise, validation fails with
ip.addresses: this property is not allowed for method=disabled
We want to have some guaranteed order when comparing different connections.
So, in case of equal timestamps, proceed with comparing more properties.
It makes sense to consider the autoconnect-priority next.
This is what get_existing_connection() needs, thus we no longer
need to pre-sort the list.
NMPolicy's auto_activate_device() wants to sort by autoconnect-priority,
nm_utils_cmp_connection_by_autoconnect_priority() but fallback to the default
nm_settings_connection_cmp_default(), which includes the timestamp.
Extend nm_settings_connection_cmp_default() to consider the
autoconnect-priority as well. Thus change behavior so that
nm_settings_connection_cmp_default() is the sort order that
auto_activate_device() wants. That makes sense, as
nm_settings_connection_cmp_default() already considered the
ability to autoconnect as first. Hence, it should also honor
the autoconnect priority.
When doing that, rename nm_settings_connection_cmp_default()
to nm_settings_connection_cmp_autoconnect_priority().
We call these functions a lot. A GSList is just the wrong tool for the
job. Refactor the code to use instead a sorted array everywhere.
This means, we malloc() one array for all connections instead
slice-allocate a GSList item for each. Also, sorting an array
is faster then sorting a GSList.
Technically, the GSList implementation had the same big-O runtime
complexity, but using an array is still faster. That is, sorting
an array and a GSList is both O(n*log(n)).
Actually, nm_settings_get_connections_sorted() used
g_slist_insert_sorted() instead of g_slist_sort(). That results
in O(n^2). That could have been fixed to have O(n*log(n)), but
instead refactor the code to use an array.
nm_settings_get_best_connections() has only one caller: to create
the hidden-SSID list.
Instead of having a highly specialised function (that accepts 3 ways for
filtering -- one of them broken, has one hard-coded way of sorting, and
a @max_requested argument), add a more generic nm_settings_get_connections_clone()
function.
Also invert nm_settings_sort_connections(). The two callers want
to sort descending, not ascending.
With commit 4f6c91d696, we aimed to
enable mac-address-randomization by default for Wi-Fi. That however
is not possible by default because it breaks various scenarios.
Also, later wifi.mac-address-randomization was deprecated in favor
of wifi.cloned-mac-address setting.
Both wifi.mac-address-randomization and wifi.cloned-mac-address support
global default values, so it is wrong to read a missing
MAC_ADDRESS_RANDOMIZATION setting as "NEVER" -- which due to
normalization also results in cloned-mac-address=permanent.
See also commit 46d53e1101 which does
something similar for keyfile.
This bug also prevents a user from clearing the cloned-mac-address:
$ nmcli connection show "$CONN"
...
802-11-wireless.cloned-mac-address: permanent
802-11-wireless.mac-address-randomization: never
...
$ nmcli connection modify "$CONN: wifi.cloned-mac-address ''
# ^ takes no effect
As workaround, you also need to clear mac-address-randomization:
$ nmcli connection modify "$CONN: wifi.cloned-mac-address '' \
wifi.mac-address-randomization default
https://mail.gnome.org/archives/networkmanager-list/2017-January/msg00060.html
The active connection has an immutable connection property, but is
cleaned asynchronously by the manager after its settings connection is
done. Fine, let's remove it from the bus first though, so that we don't
hang there with a dangling object path.
(cherry picked from commit f0e3dfdace)
