nmc_strsplit_set()'s max_token argument is broken,
because it *first* calls g_strsplit_set() and then removes
empty tokens. It wasn't an issue, because DEFINE_SETTER_PRIV_KEY()
would first already remove leading spaces, and who uses multiple
spaces anyway...
Anyway, refactor DEFINE_SETTER_PRIV_KEY() to not use it.
nmcli calls nm_setting_802_1x_set_private_key() with a password pointer that
it just got from the setting connection itself. Make this less fragile, by
not freeing the current password before assigning it.
nm_platform_ip6_address_sync() must take care not only of adding
missing addresses and removing unknown addresses, but also of the
order in which they are added. The order is important because it
determines which address is preferred by kernel.
Since we can only add addresses at the top of the list, in order to
change the position of an address we must first remove it and then
re-add it in the right position.
Probably not critical, because it will still include
the terminating NULL, and just continue to fill the
temporary buffer with static addresses.
Found by coverity.
Fixes: bfb9fd0d2f
@kind might be NULL. There are 3 forms of the hash-update functions for
string: str(), str0(), and strarr().
- str0() is when the string might be NULL.
- str() does not allow the string to be NULL
- strarr() is like str(), except it adds a G_STATIC_ASSERT()
that the argument is a C array.
The reason why a difference between str() and str0() exists, is
because str0() hashes NULL different from a "" or any other string.
This has an overhead, because it effectively must hash another bit
of information that tells whether a string was passed or not.
The reason is, that hashing a tupple of two strings should always
yield a different hash value, even for "aa",""; "a","a"; "","aa",
where naive concatentation would yield identical hash values in all
three cases.
Fixes: e75fc8279b
There are a few cases where we don't want to clear a potential
nm-generated/volatile flag, but only mark the connection as
unsaved.
Otherwise, we wrongly end up clearing these flags and the connection
is wrongly not NM_DEVICE_SYS_IFACE_STATE_EXTERNAL.
Fixes: 35dc6421de
The idea is
tfilter.<parent>=[handle <handle>] <tfilter> [<options>] [action [<action options>...]]
What works now:
[tc]
qdisc.root=handle 1234: fq_codel
qdisc.ffff:fff1=ingress
tfilter.1234:=matchall action drop
tfilter.ffff:=matchall action simple sdata Hello
Printing a g_warning() from the library is not helpful.
Client-side, libnm should support newer server versions and changing
formats. To support forward-compatibility, it should parse the received
GVariant best-effort like, without complaining.
Server-side, libnm-core should return errors when receiving invalid
configuration. It must not maintain forward-compatibility, only
backward-compatibility -- which is implemented by handling old
and newer formats. But never should server allow a configuration
that is invalid.
Currently, the libnm API cannot yet fail at this point. Hence,
it cannot return an error. It would need a strict and relaxed
parsing mode. Until that exists, just comment out the warnings.
The format for qdiscs is
qdisc.<parent>=[handle <handle>] <qdisc> [<options>...]
E.g.:
[tc]
qdisc.root=fq_codel handle de4d:
qdisc.ffff:fff1=ingress
That is pretty much what is supported at this point.
We're going to need that one for TC filter & action support.
<linux/tc_act/tc_defact.h> was moved to user-space API only in 2013
by commit 5bc3db5c9ca8407f52918b6504d3b27230defedc. Our travis CI currently
fails to build due to that.
Re-implement the header.
It only makes sense to call delete() with NMPObjects that
we obtained from the platform cache. Otherwise, if we didn't
get it from the cache in the first place, we wouldn't know
what to delete.
Hence, the input argument is (almost) always an NMPObject
in the first place. That is different from add(), where
we might create a new specific NMPlatform* instance on the
stack. For add() it makes slightly more sense to have different
functions depending on the type. For delete(), it doesn't.
