Previously for assumed connections we would never configure a default route.
That has serious problems for example in the following two scenarios:
- the default-route might have a limited lifetime from a previous
SLAAC/accept_ra setting. In this case, once we assume the connection
we must also ensure that we extend the lifetime of the default
route.
- the gateway could be received via DHCP/RA and it might change.
If we ignore default-routes for assumed connection we miss that
change.
The problem is that the notion of "assumed connection" wrongly combines
two conflicting goals (related bug bgo#746440):
a) have an external device that is entirely unmanged by NM.
b) do a seamless takeover of a previously managed connection at start,
but still fully manage.
This patch changes the handling of default-routes towards meaning b).
https://bugzilla.redhat.com/show_bug.cgi?id=1224291
Since da708059da, we would pickup the
default-route as configured externally, except at those moments when
NM re-applys the IP configuration of the interface, such as during a
DHCP lease.
That allows the user to add/remove the default-route externally (iproute).
But still, at random times (DHCP lease), we will revert those external
changes.
Extend this, that if the connection is explicitly configured as
'never-default=yes', that it tells NM not to interfere with externally
added default-routes on this device. That means, NM will only remove
any preexisting default-routes when configuring the device a first
time.
On any later attempts, NM will assume whatever is configured there.
That makes sense because the user indicated not wanting NM to
manage a default-route on that device, so if something externally
added a default-route, assume that is what the user wants.
This only affects non-assumed connections, with 'never-default=yes'.
https://bugzilla.redhat.com/show_bug.cgi?id=1205405
Also accept a NULL connection in
nm_default_route_manager_ip4_connection_has_default_route() and
nm_default_route_manager_ip6_connection_has_default_route().
D-Bus default limit of replies per connection has been lowered to 128 due to
CVE-2014-3638, see:
http://cgit.freedesktop.org/dbus/dbus/commit/?id=5bc7f9519ebc6117ba300c704794b36b87c2194bhttps://bugs.freedesktop.org/show_bug.cgi?id=81053
The limit seems to be too low and causes problems in libnm-glib, that will not
return all NetworkManager connection profiles if there are too many of them
(roughly more than the limit). As a consequence, libnm-glib based clients will
not work properly.
Lets increase the limit in our D-Bus org.freedesktop.NetworkManager.conf
configuration as we had it before.
See also older commit d5b31d55fa that did the
opposite thing (removing the limit because the default D-Bus limit was 8192 at
that time).
With GCC 5, -Wlogical-not-parentheses is enabled by -Wall and warns
about suspicious code like:
int a;
...
if (!a > 1) { ... }
Fix the following warning:
test_all.c: In function ‘test_is_static’:
test_all.c:114:32: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
ASSERT (!is_static_ip6 ("eth0") == TRUE, "is static",
^
After commits:
de0d623680 dns: don't fall back to other methods when resolvconf or netconfig fail
e573977b80 dns: allow runtime selection of resolv.conf manager
the method used to write /etc/resolv.conf is specified by a
configuration parameter and NM doesn't try other methods if the chosen
one has not success.
Restore the fallback to the 'none' method if resolvconf or netconfig
executables are not available, so that when the value of 'rc-manager'
is misconfigured the system continues to work properly.
https://bugzilla.gnome.org/show_bug.cgi?id=749286
"nm-utils-private.h" should not be used outside of libnm-core/.
core/ should only use public API or "nm-core-internal.h".
Also, "nm-setting-ip-config.h" is a public header and should
not contain internal defines. Move them to "nm-core-internal.h"
too.
Fixes: 019943bb5d
We need to know whether we can create interfaces of any given
NMDevice subclass or not. So don't rely on just the NMPlatformLink
for that information, because we won't have a platform link for
software devices before we create them.
Calling read_entire_config() without passing a @cli argument would
always have caused an assert due to unset @o_config_main_file.
That is not a real problem as that situation didn't arise. Still
fix it.
When update_dns() fails, callers expect 'error' argument to point to a
non-NULL error; but we are reusing the same variable when calling
update_resolv_conf() to update the private resolv.conf and thus the
function may return an empty error on failure.
Don't reuse the same error and pass a NULL argument instead, since we
don't care about errors when updating private resolv.conf.
Fixes: 5f9d348c20
Code that is testable often needs special hooks to work
both for unit-tests and production.
Add a function nm_utils_get_testing() that returns whether
the code is run as part of a unit-test.
For non-testing mode, nm_utils_get_testing() will return
zero (NM_UTILS_TEST_NONE). For unit tests, the test should call
_nm_utils_set_testing() to configure tested functions.
By specifing the @flags attribute, the test can enable/disable
specific behaviors.
https://bugzilla.gnome.org/show_bug.cgi?id=701112
nm_device_factory_manager_find_factory_for_link_type()
easily can see a link-type NM_LINK_TYPE_UNKNOWN because
there are many link types that NetworkManager cannot detect.
Just return NULL early.
Fixes: 71bde20c30
Support accepting more then one signal at a time.
It is to be expected, that one change in platform raises
several signals. Extend the assertion helpers to express
that.
Up to now, this code was correct. Later we will add another field
to NMPlatformIP4Route which causes the test to operate on
uninitialized data.
Instead of explicitly initializing the field, just clear the whole
struct.
Try to set the MTU of the parent Ethernet interface to match the
requested PPP MTU and MRU. This allows the negotiation of a PPP MTU
and MRU greater than 1492.
We switched to user-mode PPPoE client to work around a bug in kernel
PPPoE code that caused pppd not to be notified when the connection was
terminated with a PADT before the LCP Termination Request.
The kernel bug has now been fixed upstream with commit 287f3a943fef
"pppoe: Use workqueue to die properly when a PADT is received", queued
for v4.1.
Since the issue affected only very particular scenarios and could
somehow be solved with the right configuration (see bugzilla entry),
we can safely revert the patch and restore the use of kernel mode
PPPoE.
This reverts commit 7955806a02.
https://bugzilla.gnome.org/show_bug.cgi?id=742939
