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
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
It might be that the user didn't supply the secrets in time and the dbus call
timed out. The agent should now hide the secrets dialog and we must let it know.
https://bugzilla.redhat.com/show_bug.cgi?id=1272023
It does more than intended; apart from denying messages to that particular
interface it also denies all messages non-qualified with an interface globally.
From the dbus-daemon manual:
Be careful with send_interface/receive_interface, because the
interface field in messages is optional. In particular, do NOT
specify <deny send_interface="org.foo.Bar"/>! This will cause
no-interface messages to be blocked for all services, which is almost
certainly not what you intended. Always use rules of the form: <deny
send_interface="org.foo.Bar" send_destination="org.foo.Service"/>
We can just safely remove those rules, since we're sufficiently protected
by the send_destination matches and method calls are disallowed by default
anyway.
For an explicit user-request, we relax some checks when searching for a suitable
device; such as requiring-carrier.
Without this patch, a connection-up while the device has no carrier yet,
would fail right away with "No suitable device found for this connection."
https://bugzilla.redhat.com/show_bug.cgi?id=1079353
Fixes: 0bfe635119
