All current users of NM_IN_SET() would rather use short-circuit evalation
(or don't care). It seems that doing it by default seems favorable.
The only downside is, that this might have somewhat unexpected behavior
to a user who expects a regular function (which would evaluate always
all arguments).
Fixes: 7860ef959a
When having a hash-of-hashes where each hash is indexed by a name,
(such as GKeyFile), you can either implement it as a hash-of-hashes
or define your own version of indexes that pack both levels of names
into one key.
This is an implementation of such a key. Use it as:
GHashTable *hash = g_hash_table_new_full (_nm_utils_strstrdictkey_hash,
_nm_utils_strstrdictkey_equal,
g_free, _destroy_value);
and create keys via:
NMUtilsStrStrDictKey *k = _nm_utils_strstrdictkey_create (s1, s2);
For lookup you can use static strings (note that the static string
might increase the size of the binary):
g_hash_table_contains (hash, _nm_utils_strstrdictkey_static ("outer", "inner"))
Rather than randomly including one or more of <glib.h>,
<glib-object.h>, and <gio/gio.h> everywhere (and forgetting to include
"nm-glib-compat.h" most of the time), rename nm-glib-compat.h to
nm-glib.h, include <gio/gio.h> from there, and then change all .c
files in NM to include "nm-glib.h" rather than including the glib
headers directly.
(Public headers files still have to include the real glib headers,
since nm-glib.h isn't installed...)
Also, remove glib includes from header files that are already
including a base object header file (which must itself already include
the glib headers).
Add functions nm_utils_enum_to_str() and nm_utils_enum_from_str()
which can be used to perform conversions between enum values and
strings, passing the GType automatically generated for every enum by
glib-mkenums.
warning: function declaration isn’t a prototype [-Wstrict-prototypes]
In C function() and function(void) are two different prototypes (as opposed to
C++).
function() accepts an arbitrary number of arguments
function(void) accepts zero arguments
The property is used for controlling whether slaves should be brought up with
a master connection. If 0, activating the master will not activate slaves.
But if set to 1, activating the master will bring up slaves as well.
The property can have the third state (-1), meaning that the value is default.
That is either a value set in the configuration file for the property, or 0.
Add a 'metered' enum property to NMSettingConnection with possible
values: unknown,yes,no. The value indicates the presence of limitations
in the amount of traffic flowing through the connection.
In _nm_setting_new_from_dbus(), verify that the properties have the
right types, and return an error if not. (In particular, don't crash
if someone tries to assign a GBytes-valued property a non-'ay' value.)
For IPv4 addresses, the binary representation is in network-order,
contrary to host-order. It's better to choose addresses for testing
that are differently on big and little endian systems.
Error: CHECKED_RETURN (CWE-252): [#def12]
NetworkManager-0.9.11.0/libnm-core/tests/test-general.c:348: check_return: Calling "nm_setting_verify" without checking return value (as is done elsewhere 37 out of 45 times).
...
Before we would just call verify() and only return valid connections
without attempting to fix them.
It is better to use normalize(), because that function is especially there to
accept and repair deprecated configurations that would no longer verify().
This changes behavior in the way that the function now accepts connections
that would have been rejected before.
Since commit b88715e05b normalize() also
adds a missing UUID. Hence this also affects the DBUS method 'AddConnection'
in that it now accepts connections without UUID. Previously, clients were
required to set a UUID for the new connection, now NM core can create a random
one if no UUID is set.
https://bugzilla.gnome.org/show_bug.cgi?id=740813
There are different types (variants) of UUIDs defined.
Especially variants 3 and 5 are name based variants (rfc4122).
The way we create our UUIDs in nm_utils_uuid_generate_from_string()
however does not create them according to RFC and does not set
the flags to indicate the variant.
Modify the signature of nm_utils_uuid_generate_from_string() to accept
a "uuid_type" argument, so that we later can add other algorithms without
breaking API.
We were always using the gateway field of the first address in
ipv4.addresses / ipv6.addresses to set the gateway, but to be
compatible with old behavior, we should actually be using the first
non-0 gateway field (if the first one is 0).
Fixes testing on 32-bit arches:
/core/general/test_setting_compare_timestamp:
(./test-general:29331): GLib-GObject-WARNING **: g_object_set_valist: object class `NMSettingConnection' has no property named `$?\xff\xff\x89t$0\x89|$4\xe8\u001c\x98\xff\xff\x85\xc0tM\x83\xf8\xfft3\x8dT$(\xc7D$\u0008'
/bin/sh: line 5: 29331 Trace/breakpoint trap ${dir}$tst
FAIL: test-general
Fixes: 093a3c88d0
Although libnm filters out properties received from the daemon that it
doesn't understand, there may be other clients that do not. In
particular, a client might call GetSettings() on a connection, update
the ipv4.addresses property in the returned dictionary, and then pass
the dictionary to Update(). In that case, the updated dictionary would
contain ipv4.address-data, but it would not reflect the changes the
client intended to make.
Fix this by changing the daemon side to prefer the legacy properties
to the new ones if both are set, and changing the client side to not
send the legacy properties (since we don't support new clients talking
to old servers anyway).
config.h should be included from every .c file, and it should be
included before any other include. Fix that.
(As a side effect of how I did this, this also changes us to
consistently use "config.h" rather than <config.h>. To the extent that
it matters [which is not much], quotes are more correct anyway, since
we're talking about a file in our own build tree, not a system
include.)
Make the type return GBytes since most in-tree users want that.
Allow the function to accept many more formats as valid hex, including
bytes delimited by ':' and a leading '0x'.
Add AddressData and RouteData properties to NMSettingIPConfig and
NMIP[46]Config. These are like the existing "addresses" and "routes"
properties, but using strings and containing additional attributes,
like NMIPAddress and NMIPRoute.
This only affects the D-Bus representations; there are no API changes
to NMSettingIP{,4,6}Config or NMIP{4,6}Config as a result of this; the
additional information is just added to the existing 'addresses' and
'routes' properties.
NMSettingIP4Config and NMSettingIP6Config now always generate both
old-style data ('addresses', 'address-labels', 'routes') and new-style
data ('address-data', 'gateway', 'route-data') when serializing to
D-Bus, for backward compatibility. When deserializing, they will fill
in the 'addresses' and 'routes' properties from the new-style data if
it is present (ignoring the old-style data), or from the old-style
data if the new-style isn't present.
The daemon-side NMIP4Config and NMIP6Config always emit changes for
both 'Addresses'/'Routes' and 'AddressData'/'RouteData'. The
libnm-side classes initially listen for changes on both properties,
but start ignoring the 'Addresses' and 'Routes' properties once they
know the daemon is also providing 'AddressData' and 'RouteData'.
The gateway is a global property of the IPv4/IPv6 configuration, not
an attribute of any particular address. So represent it as such in the
API; remove the gateway from NMIPAddress, and add it to
NMSettingIPConfig.
Behind the scenes, the gateway is still serialized along with the
first address in NMSettingIPConfig:addresses, and is deserialized from
that if the settings dictionary doesn't contain a 'gateway' key.
Adjust nmcli's interactive mode to prompt for IP addresses and gateway
separately. (Patch partly from Jirka Klimeš.)
Split a base NMSettingIPConfig class out of NMSettingIP4Config and
NMSettingIP6Config, and update things accordingly.
Further simplifications of now-redundant IPv4-vs-IPv6 code are
possible, and should happen in the future.
Add key-value attributes to NMIPAddress and NMIPRoute, and use them to
store IPv4 address labels. Demote NMSettingIP4Config:address-labels to
a D-Bus-only property, and arrange for :addresses setter to read the
labels out of that property when creating the addresses.
Merge NMIP4Address and NMIP6Address into NMIPAddress, and NMIP4Route
and NMIP6Route into NMIPRoute. The new types represent IP addresses as
strings, rather than in binary, and so are address-family agnostic.
