Just code cleanup: This is much less error-prone than manual nesting,
and will mesh very well with future changes to use the libgsystem
cleanup macros.
Accomodate nm-netlink-monitor.c to the change by moving around utility
functions and making them static (removing if not used). Unsubscription
of rtnl groups is not necessary and the whole process will be eventually
moved to nm-platform.
Confusingly, nm-platform-compat's rtnl_link_set_oif adds a new nexthop
with ifindex set, while rtnl_link_set_gateway sets gateway for an
existing nexthop. Keeping the behavior to avoid potential problems.
device_sync_from_netlink() and nm_netlink_request_ip6_info() are now
delayed, so that they are called only once for a series of events. This
makes the IPv6 processing and especially debug messages more sane.
NL_AUTO_PROVIDE is not a valid flag for this call and it's coincidental
with ROUTE_CACHE_CONTENT, which is certainly not what we want.
NETLINK_ROUTE is a netlink family, not an address family. It is
coincidental with AF_UNSPEC which is what we actually want.
Stop logging the whole list of addresses as we already have new and lost
addresses logged. Stop putting 'state' and 'ra_flags' in almost every
message since changes of those are already logged. Log target state
change.
The config file can specify a dhclient script, which gets used instead
of what NM passes on the command-line. Make sure that script gets
ignored in the final dhclient config, because the script NM passes
is the script that needs to be used to pass data back to NM. People
may have old dhclient.conf files lying around that get picked up and
we don't want any script specified there to interfere.
GValueArray is deprecated. Unfortunately, it's part of our API right now,
so we have to keep it around for a while. But since it's deprecated, and
we want to know about *other* deprecations, we have to suppress deprecations
about GValueArray. Unfortunately using macros to do that (eg in
nm-gvaluearray-compat.h) exposes some compiler bugs due to the combination
of parentheses/braces and #pragma from G_GNUC_BEGIN_IGNORE_DEPRECATIONS,
resulting in warnings like:
nm-utils.c:920:9: error: expected expression before ‘#pragma’
Work around this by not trying to stuff what's now a macro (eg
g_value_array_get_nth) into what's already a macro (G_VALUE_TYPE).
There's probably a better way to do this...
Remove the HostnameThread stuff from nm-policy-hostname and just use
GResolver instead. Move the one remaining nm-policy-hostname function
into nm-policy.
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.
data_iface is the serial port over which PPP should be run, so
we need to preserve that and not overwrite it with the PPP interface
name. When reconnecting, pppd wants the TTY to run PPP over (eg the
ModemManager data_port like ttyUSB0) but if we overwrote that with
ppp0 on the last connection, that's extremely unhelpful and pppd will
fail to start.
When built with MM1 support, the restart handling code here would
fail for both old MM and new MM. The code should ignore the
name owner change even if the incoming bus name is *neither*
old MM nor new MM. It wasn't doing that.
Seems that NLM_F_CREATE isn't enough, we need to replace anything
that's already there. Oddly, this is even though we already cleaned
out anything that was already there.
Otherwise, priv->accept_ra_path would be NULL, which isn't very
useful and makes nm_utils_do_sysctl() angry. No reason we shouldn't
always create priv->accept_ra_path in the future though.
https://bugzilla.gnome.org/show_bug.cgi?id=691213
