Constructing the libnl3 object only to parse the message
is wasteful. It involves several memory allocations, thread
synchronization and parsing fields that we don't care about.
But moreover, older libnl version might not support all the
fields we are interested in, hence we have workarounds like
_nl_link_parse_info_data(). Certain features might not fully
work unless libnl supports it too (although kernel would).
As we already parse the data ourselves sometimes, just go
all they way and don't construct the intermediate libnl object.
This will allow us to drop the _nl_link_parse_info_data() workarounds
in next commits. That is important, because _nl_link_parse_info_data()
sidesteps our platform cache and is not in sync with the cache (not to
mention the extra work to explicitly refetch the data on every lookup).
Also, it gets us 60% on the way to no longer needing 'libnl-route-3.so'
at all and eventually drop requiring the library.
This function only accesses sysctl function to retrieve the tun-properties.
sysctl is already defined in the base class and equally inherited by linux
and fake platform. Move the implementation there.
For link objects, nmp_object_cmp() did not consider the private fields and
thus behaved different then nmp_object_equal(). This is wrong.
Implement nmp_object_equal() based on compare.
Arguably, it is more convenient to use the static buffer as
it saves typing.
But having such a low-level function use a static buffer also
limits the way how to use it. As it was, you could not avoid
using the static buffer.
E.g. you cannot do:
char buf[100];
_LOGD ("nmp-object: %s; platform-link: %s",
nmp_object_to_string (nmpobj, buf, sizeof(buf)),
nm_platform_link_to_string (link));
This will fail for non-obvious reasons because both
to-string functions end up using the same static buffer.
Also change the to-string implementations to accept NULL
as valid and return it as "(null)".
https://bugzilla.gnome.org/show_bug.cgi?id=756427
The configuration is going to be applied on the parent interface.
If we didn't do this, an attempt to add a route would result in an assertion
failure:
nm-ip4-config.c:1475:nm_ip4_config_add_route: assertion failed: (priv->ifindex)
gcc 5.1.1 wrongly warns about uninitialized variable @r2 when compiling
with -Og. Refactor the code to avoid the warnings.
Related: https://github.com/systemd/systemd/pull/1735
make[5]: Entering directory './NetworkManager/libnm-core/tests'
CC test-general.o
test-general.c: In function ‘test_g_hash_table_get_keys_as_array’:
test-general.c:4552:69: error: ‘length’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
test-general.c:4543:8: note: ‘length’ was declared here
guint length;
^
request_free() can be called on an error.
Oct 27 20:27:46 localhost.localdomain nm-dispatcher[2328]: #1 'pre-up': completed: invalid request: Missing or invalid required value path!
Oct 27 20:27:46 localhost.localdomain nm-dispatcher[2328]: **
Oct 27 20:27:46 localhost.localdomain nm-dispatcher[2328]: ERROR:nm-dispatcher.c:203:request_free: assertion failed (request->num_scripts_done == request->scripts->len): (0 == 1)
Fixes: 1999723241https://bugzilla.redhat.com/show_bug.cgi?id=1275813
network.target is a very early boot target which basically says "I can start
opening sockets now". It has nothing to do with being connected to the internet
and is often required by early boot services as well.
Drop the unnecessary and wrong Wants=/Before=network.target to avoid dependency
cycles and boot delays.
https://bugzilla.gnome.org/show_bug.cgi?id=746039https://launchpad.net/1430280
gcc complains with the following warning:
"comparison between 'enum <anonymous>' and 'enum vlan_flags'"
Cast one side of the comparison to avoid that.
Fixes: ee7414ebc8
Because Bluez5 dropped DUN support, NM must do that manually which
includes emulating the "connected" property for Bluetooth devices when
DUN is used. It does this by setting priv->connected = TRUE in
nm_bluez_device_connect_finish().
But for PAN, when NM does process the 'connected' property change
notification, priv->connected is already TRUE and
_take_variant_property_connected() does nothing. Hence the
corresponding GObject property notification is not emitted,
nm-device-bt.c::check_connect_continue() will never return success, and
the activation times out.
To fix this, ensure that GObject notifications are emitted when the
device is connected, even if emulated internally.
https://mail.gnome.org/archives/networkmanager-list/2015-October/msg00053.htmlhttps://bugzilla.redhat.com/show_bug.cgi?id=1255284
