Settings with all-default values are not written to reduce
complexity of the keyfile (and be more human-readable friendly)
and that includes VLAN settings with a VLAN ID of zero. So
when reading this file back, if there is no 'base type' setting
(eg, the setting specified by the connection::type property)
then just add that setting. nm_connection_verify() will catch
cases where an empty 'base type' setting is invalid.
Add these aliases for the setting names '802-3-ethernet',
'802-11-wireless', and '802-11-wireless-security' and write them by
default. It's much friendlier for administrators to type, and a lot
less ugly.
Also works for:
[connection]
type=ethernet
test-keyfile.c: In function 'test_read_string_ssid':
test-keyfile.c:1154:51: error: argument to 'sizeof' in 'memcmp' call is the
same expression as the second source; did you mean to provide an explicit
length? [-Werror=sizeof-pointer-memaccess]
ASSERT (memcmp (array->data, expected_ssid, sizeof (expected_ssid)) == 0,
GObject creation cannot normally fail, except for types that implement
GInitable and take a GError in their _new() method. Some NM types
override constructor() and return NULL in some cases, but these
generally only happen in the case of programmer error (eg, failing to
set a mandatory property), and so crashing is reasonable (and most
likely inevitable anyway).
So, remove all NULL checks after calls to g_object_new() and its
myriad wrappers.
https://bugzilla.gnome.org/show_bug.cgi?id=693678
Use --enable-doc and --enable-tests instead of --with-docs and
--with-tests. This is consistent with other features and with
--enable-gtk-doc option. Support current variants as fallback.
Don't build tests unless --enable-tests is specified.
"InfiniBand" has a capital "B". Fix that everywhere it's being used as
a human-readable string.
In particular, the RH initscripts recognize "TYPE=infiniband" and
"TYPE=InfiniBand", but not "TYPE=Infiniband", which is what we were
writing before.
The regex was capturing integers larger than 3 digits, which aren't
valid SSID integer list items because each byte of the SSID cannot be
larger than 255. Add an explicit testcase for intlist SSIDs too.
The previous regex was causing a testcase failure with an SSID of
'1337' which it was interpreting as a single element intlist, but
should have been interpreted as a string since it's clear > 255.
The keyfile code has to handle a few different formats of cert/key values,
and wasn't doing a good enough job of detecting plain paths as values. By
default the writer will write out a plain path (ie, not prefixed with file://)
and the reader will handle that correctly, *unless* that file does not
exist, at which the reader assumed it was a byte array. This caused the
read-in keyfile not to match the in-memory connection (since the in-memory
connection though the cert/key held a path, but the read-in one thought it
contained a blob) and this seems to eventually have triggered a write-out
with the new values (as a blob), which would then drop a .pem file into
system-connections/ containing the path that should have been in the
keyfile in the first place.
This all happened because we assumed that the given path for the cert or
key would actually be valid, which doesn't seem to be the case for a lot
of people. Clearly these connections won't work (since the certificate or
key does not exist) but the keyfile plugin shouldn't be messing up the
connection's settings at the very least.
Fix that by handling the check of whether the cert/key data is a path or
not in a less restrictive manner and add some testcases to make sure that
everything works as we expect.
If the cert/key path is relative to the keyfile then don't
bother writing the absolute path out. This also prevents the
keyfile plugin from rewriting a relative path to an absolute one,
preventing some annoyance for people that hand-edit keyfiles.
Passing a relative path to wpa_supplicant does no good since the supplicant
may not have the same working directory as NetworkManager. Relative paths
used in keyfiles are assumed to be relative to the keyfile itself anyway,
so actually use the absolute path we compute for the cert/key instead of
leaving it relative.
