When adding the same addresses from different sources, we want to
preserve the times with the later expiry . If the new address comes
from the kernel itself, we treat it specially and prefer the times
from other sources.
Signed-off-by: Thomas Haller <thaller@redhat.com>
This compares two addresses and returns which one has a longer
remaining life (i.e. a later expiry timestamp).
Signed-off-by: Thomas Haller <thaller@redhat.com>
Especially the calculation of timestamps is identicall for addresses.
By creating a "base struct", we can use the same code for that, because
NMPlatformIP4Address and NMPlatformIP6Address can now both be treated as
NMPlatformIPAddress (and the same for routes).
Signed-off-by: Thomas Haller <thaller@redhat.com>
Before platform raised 3 signals for each object type. Combine
them into one and add a new parameter @change_type to distinguish
between the change type.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Makes the function working for link destinations longer then 127 bytes and
fixes a potential bug that the result of readlink() was not zero
terminated for long paths.
Probably this would be no problem, but better be save.
Related: https://bugzilla.redhat.com/attachment.cgi?id=885371
Signed-off-by: Thomas Haller <thaller@redhat.com>
Interpret the configuration option main.debug and the
environment variable NM_DEBUG as a comma separated list
of debugging options (parsed with g_parse_debug_string()).
Currently only the option "RLIMIT_CORE" is supported, to set
the core dump size to unlimited.
Signed-off-by: Thomas Haller <thaller@redhat.com>
In case of DHCP4, DHCP6 and/or SLAAC, delay "startup complete" until
both IPv4 and IPv6 are ready. This especially has an effect on
nm-online/NetworkManager-wait-online.service, which blocks until
configuration of both IPv4 and IPv6 is ready.
We queue a pending_action when automatic configuration starts and
remove it again, when we receive an address. Before, "startup complete"
was reached when either one of the two IP protocols was configured.
https://bugzilla.redhat.com/show_bug.cgi?id=1086906
Signed-off-by: Thomas Haller <thaller@redhat.com>
Add a parameter to nm_device_add_pending_action() to silently
accept adding duplicate actions.
Same for nm_device_remove_pending_action(), to silently ignore
removing non-pending actions.
Signed-off-by: Thomas Haller <thaller@redhat.com>
dfe194ee made it so that we don't use "public suffixes" as resolv.conf
search domains (eg, we don't add "search com" if the hostname is
"example.com"). However, if this results in us writing a resolv.conf
with no "search" line at all, then the resolver will fall back to
using the parent domain of the hostname as a search domain anyway,
thwarting us.
To fix that, use the domain itself as a search domain in this case,
since that's likely to be the expected behavior anyway. (And even if
it's not, there doesn't appear to be any way to block the resolver
from using the hostname's parent domain as a search domain unless we
specify at least one search domain ourselves.)
https://bugzilla.gnome.org/show_bug.cgi?id=729137
resolv.conf(5) says:
The domain and search keywords are mutually exclusive. If more than
one instance of these keywords is present, the last instance wins.
NM always writes out a "search" line if it writes a "domain" line, so
the "domain" line is always a no-op. So drop it.
https://bugzilla.gnome.org/show_bug.cgi?id=729137
test_read_wired_aliases_bad() would succeed or fail depending on the
order that ifcfg-aliasem1:1 and ifcfg-aliasem1:2 got read from disk.
Fix this by splitting it into two separate tests, each with only a
single alias.
This results in some nice coloring. Only move the tests that are called
without arguments from check-local to TESTS.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Use g_test_expect_message() in the various daemon-side test programs,
to avoid spewing error messages when (successfully) running "make
check".
The ifnet and ifupdown plugins are extremely verbose, so they were
partially "fixed" by turning down the logging level from INFO to WARN
in those tests.
test-dhcp-options needed to be converted to gtestutils so that the
newly-added check in nm-dbus-manager would recognize it as a test
program and not try to create a private bus.
When running test programs, don't try to create a private bus, since
it will fail if the user isn't root or if NetworkManager is currently
running, and it isn't what we want anyway.
Remove the PLUGIN_PRINT() and PLUGIN_WARN() macros and use the
standard NM logging functions instead.
Also changed PLUGIN_PRINT("error: ...") to nm_log_warn("...") in
places.
The dispatcher would kill scripts after 3 seconds, but on
heavily-loaded machines, that was sometimes too short even for simple
scripts. Bump the timeout up to 20 seconds instead (and change the
10-second quit-on-idle timer to not run when a script is running).
Also change the D-Bus call timeout in the daemon to 30 seconds, so
that it only triggers if something goes really wrong and the action
timeout fails.
Now we use init_link to print the rtnllink object, so be more
resilient to incompletly initilized objects and just set the
fields to NULL.
This fixes the (non harmful) warning:
<debug> [1397563880.690580] [platform/nm-linux-platform.c:1950] link_change_flags(): link: change 3: flags set 'up' (1)
init_link: assertion 'rtnl_link_get_name (rtnllink)' failed
file platform/nm-linux-platform.c: line 1021 (to_string_link): should not be reached
<error> [1397563880.690632] [platform/nm-linux-platform.c:1836] link_change(): Netlink error changing link (invalid link 0x7f88b5cf93c0): Unspecific failure
Signed-off-by: Thomas Haller <thaller@redhat.com>
We have to check the previous base device state in process_secondaries() when
making a state change. The device might got disconnected in the meantime and
thus the transition from DISCONNECTED to ACTIVATED or FAILED would have been
incorrect.
Logs showing the problem:
NetworkManager[2655]: <info> (eth0): disconnecting for new activation request.
NetworkManager[2655]: <info> (eth0): device state change: secondaries -> deactivating (reason 'none') [90 110 0]
NetworkManager[2655]: <info> (eth0): device state change: deactivating -> disconnected (reason 'none') [110 30 0]
NetworkManager[2655]: <info> (eth0): deactivating device (reason 'none') [0]
NetworkManager[2655]: <info> (eth0): canceled DHCP transaction, DHCP client pid 11409
NetworkManager[2655]: <info> NetworkManager state is now DISCONNECTED
NetworkManager[2655]: (devices/nm-device.c:6591):nm_device_state_changed: runtime check failed: (priv->in_state_changed == FALSE)
NetworkManager[2655]: <info> (eth0): device state change: disconnected -> failed (reason 'secondary-connection-failed') [30 120 54]
NetworkManager[2655]: <warn> Activation (eth0) failed for connection '<unknown>'
NetworkManager[2655]: <warn> (eth0): add_pending_action (4): 'queued state change to disconnected' already added
NetworkManager[2655]: file devices/nm-device.c: line 7682 (nm_device_add_pending_action): should not be reached
NetworkManager[2655]: <info> Activation (eth0) starting connection 'ethernet-12'
NetworkManager[2655]: <info> Activation (eth0) Stage 1 of 5 (Device Prepare) scheduled...
NetworkManager[2655]: <info> (eth0): device state change: failed -> disconnected (reason 'none') [120 30 0]
NetworkManager[2655]: <info> (eth0): deactivating device (reason 'none') [0]
NetworkManager[2655]: <warn> (eth0): remove_pending_action (2): 'queued state change to disconnected' never added
NetworkManager[2655]: file devices/nm-device.c: line 7733 (nm_device_remove_pending_action): should not be reached
NetworkManager[2655]: <info> VPN service 'openvpn' disappeared
https://bugzilla.redhat.com/show_bug.cgi?id=1055099https://bugzilla.redhat.com/show_bug.cgi?id=1055101
The kernel PPPoE code disconnects when it receives a PADT frame, but
doesn't notify userland about it. So if the server sends a PPPoE PADT
without having sent the standard PPP LCP Termination request first,
then pppd (and thus NetworkManager) will not know that the connection
has been disconnected.
This should eventually be fixed in the kernel, but for now, work
around this by using the userland pppoe client rather than the kernel
code.
