A gnu extension to printf adds the format specifier "%m"
to print @errno. To preserve the error number until the
point where the logging statement is constructed, pass
it as an additional argument to _nm_log().
This is not (yet) used from NM internal code. But systemd is adding
similar functionality to its logging functions. Add the same also to
nm-logging, to support systemd's usage of "%m".
This does not yet work, because the --order option
contains colons which bash completion considers as
separaters.
For now, implement it and ignore that problem. It
works correctly until you specify more then one
order-columns separated by colon.
https://bugzilla.gnome.org/show_bug.cgi?id=738613
Fixes: 40e98f5d68
dhclient only supports fqdn.fqdn for server DDNS updates with
DHCPv6. And even though the underlying DHCP options that fqdn.fqdn
controls allow non-qualified hostnames on the wire, dhclient does
not. So we must require a fully-qualified name for DHCPv6.
Second, while no-client-updates seems like it should be "off", doing
that apparently makes dhclient set the "O" flag to 1 which appears to
be a bug, and results in the server not doing the DDNS update. So
we must stop setting that option too.
Found by: Alexander Groß
No functional change, a cosmetic thing for now.
We want it set before any routes are added and ensure routes have a valid
ifindex before we pass it to the platform.
In a future NMRouteManager will need to look up the route for a device in
its cache thus we'll need to make sure routes passed to the it have an
appropriate ifindex set.
No functional change, a cosmetic thing for now.
We want it set before any routes are added and ensure routes have a valid
ifindex before we pass it to the platform.
In a future NMRouteManager will need to look up the route for a device in
its cache thus we'll need to make sure routes passed to the it have an
appropriate ifindex set.
Create a NMRouteManager singleton.
Refactor, no functional changes apart from change of log domain from
LOGD_PLATFORM to LOGD_CORE.
Subsequent commit will keep track of the conflicting routes, avoid overwriting
older ones with newer ones and apply the new ones when the old ones go away.
When ipv4=auto and ipv6=auto, we'll first try with the IPv4v6 PDP type, and if
that fails (e.g. if either the modem or the operator doesn't support it), we'll
fallback to trying with IPv4 or IPv6 PDP types (only if may-fail configuration
allows it).
Patch based on a previous implementation by Dan Williams <dcbw@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=733696
Since GCC 4.4, gcc does not warn about unknown -Wno-* flags. At
least, it does not warning unless another warning is raised as well
(https://gcc.gnu.org/wiki/FAQ#wnowarning).
We didn't notice up to now, because we only tested flags that GCC
actually supports.
Hack around this, by checking for the -W* counterpart instead.
It's always user requested -- auto activation never happens on already active
devices. nm_device_release_one_slave() rightly asserts teardown with
(un)configuration does not happen for no reason at all.
https://bugzilla.gnome.org/show_bug.cgi?id=744812
