Bonding options are written straight into [bond] group like:
[bond]
interface-name=bbb
mode-active-backup
miimon=300
So we have to handle them explicitly.
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
Avoid warnings about GValueArray being deprecated by adding macros
that wrap G_GNUC_BEGIN_IGNORE_DEPRECATIONS /
G_GNUC_END_IGNORE_DEPRECATIONS around the GValueArray calls.
You can now use 'address=' even for IPv6 and it's the encouraged way
to set up a single address manually. For multiple addresses,
'address0=', 'address1=', etc, should be preferred.
Example:
address=10.0.0.15/24/10.0.0.1
address0=192.168.0.1/24
address1=10.0.0.16/32
Example (backward compatibility):
addresses=10.0.0.15/24/10.0.0.1
addresses0=192.168.0.1/24
addresses1=10.0.0.16/32
IPv4 and IPv6 address configuration is now handled together and supports
the following syntax (slashes can be replaced with semicolons):
address/plen
address/plen,gateway
IPv4 and IPv6 route configuration is also handled uniformly and supports
the following syntax:
address/plen (for device routes)
address/plen,gateway (for gateway routes)
address/plen,gateway,metric (for gateway routes with metric)
For compatibility reasons, slash (/), comma (,) and semicolon (;) are
considered equal by the parser. The /plen part is optional for both
addresses and routes for compatibility reasons.
Leaving out the prefix length is not considered a good idea. IPv6
addresses default to 64 and IPv4 now defaults to 24 which is the closest
possible IPv4 counterpart. Routes default to single addresses.
Example 1:
[ipv4]
method=manual
addresses1=192.168.56.5/24,192.168.56.1
addresses2=192.168.57.5/24
routes1=4.5.6.0/24
routes2=1.2.3.0/24,4.5.6.7
routes3=7.8.9.0/24,4.5.6.7,99
[ipv6]
method=manual
addresses1=2001:db8:a🅱️:3/64,2001:db8:a🅱️:1
addresses2=2001:db8:c:d::3/64
routes1=2001:db8:e:f::/64,2001:db8:a🅱️:4
Example 2 (equivalent):
[ipv4]
method=manual
addresses1=192.168.56.5;24;192.168.56.1
addresses2=192.168.57.5;24
routes1=4.5.6.0;24
routes2=1.2.3.0;24;4.5.6.7
routes3=7.8.9.0;24;4.5.6.7;99
[ipv6]
method=manual
addresses1=2001:db8:a🅱️:3;64;2001:db8:a🅱️:1
addresses2=2001:db8:c:d::3;64
routes1=2001:db8:e:f::;64;2001:db8:a🅱️:4
For writing, I have arbitrarily chosen one of the formats 'reader'
can parse. Address and prefix length are separated by slash (/),
everything else is separated by comma (,).
addresses1=address/plen,gateway
routes1=address/plen,gateway,metric
Note: The modified 'reader' exposes a bug in the 'writer' and ignores
out badly-formatted routes. This problem is also fixed by this
commit. Keyfile tests now pass.
The ctype macros (eg, isalnum(), tolower()) are locale-dependent. Use
glib's ASCII-only versions instead.
Also, replace isascii() with g_ascii_isprint(), since isascii()
accepts control characters, which isn't what the code wanted in any of
the places where it was using it.
nm_utils_hwaddr_ntoa() and nm_utils_hwaddr_aton() are like
ether_ntoa()/ether_aton(), but handle IPoIB too.
nm_utils_hwaddr_atoba() is like _aton() but returns a GByteArray,
since that's what's wanted in many places.
Also remove nm_ether_ntop() and replace uses of it with
nm_utils_hwaddr_ntoa().
Even with the previous fix some cases were still undistinguishable. For example,SSID like '11;12;' is both valid an intlist and a string.
So this commit:
- escapes ';' character with '\' when writing, and removes '\' while reading
This clearly differentiates between intlist x strings.
- changes regex pattern to allow spaces before ';' in intlist format
Intlists have to end with a ';' since that's how they are written
out, and that's the only way we can actually distinguish between
intlist SSIDs and string SSIDs, really.
SSIDs don't want NULL termination, but some of the certificate code
checked for it. New-style plain strings would never be NULL
terminated (by accident) so fix that and make the code simpler too.
Found by Gary Ching-Pang Lin <chingpang@gmail.com>
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.
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.
