the --timeout command line option is a custom feature added in some
linux distributions (fedora). Passing that command line argument will
make dhclient fail if the binary does not support it, preventing
activation of dhcp based connections.
Worse, the option has just been recently changed from "-timeout", so
that we are currently incompatibile with Centos, RedHat and older
versions of Fedora too.
Leverage the "timeout" option in dhclient config file: it will produce
the expected behavior and will be universally supported.
Fixes test: dhcp-timeout
Fixes: fa46736013https://bugzilla.redhat.com/show_bug.cgi?id=1491243
Let's not treat those routes special. I think this was originally done, because
we relied on kernel to add the IPv4 device route, so we would ignore RTPROT_KERNEL
routes and not delete them.
We want to track them for various reasons:
- for consistency, there is nothing special except that they might be
added by kernel.
- we expose the routes of NMIP4Config/NMIP6Config on D-Bus. That should
include also routes such as device routes. Note, this commit changes
that we now expose device routes on D-Bus too.
For IPv6, we create device routes when processing the RA and add it to
NMIP6Config like any other route. For IPv4 we didn't do that. Instead
we created the list of device routes during nm_ip4_config_commit() and
passed it to nm_platform_ip_route_sync().
When merging IP addresses, we keep the best addr_source and the internally
configured timestamps. Since the check for the timestamp considers addr_source,
we must move the check before merging addr_source.
For kernel, route ID compare identical according to NM_PLATFORM_IP_ROUTE_CMP_TYPE_ID.
Well, mostly. In practice, NM ignores several route properties that
kernel considers part of the ID too. This leaves the possibility that
kernel allows addition of two routes that compare idential for
NetworkManager.
Anyway, NMIP4Config/NMIP6Config should use the same equality as platform
cache. Otherwise, there is the odd situation that ip-config merges routes
that are treated as different by kernel.
For IP addresses the ID operator already corresponded to what kernel
does. There is no change for addresses.
Note that NMSettingIPConfig also uses a different algorithm for
comparing routes. But that doesn't really matter here, it it differed
before too.
CC libnm-core/libnm_core_libnm_core_la-nm-utils.lo
libnm-core/nm-utils.c:210:6: error: variable 'encodings' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized]
if (lang) {
^~~~
libnm-core/nm-utils.c:220:7: note: uninitialized use occurs here
if (!encodings) {
^~~~~~~~~
libnm-core/nm-utils.c:210:2: note: remove the 'if' if its condition is always true
if (lang) {
^~~~~~~~~~
libnm-core/nm-utils.c:198:30: note: initialize the variable 'encodings' to silence this warning
const char *const *encodings;
^
= NULL
Fixes: 28a0627481
There are basically three options:
1) use a separate _get_fcn_gobject_dcb_priority() getter and
implement them as a new type _pt_gobject_dcb_priority.
2a) implement them as _pt_gobject_int and set nicks as value_infos,
repeating the nicks 3 times.
2b) like 2a, but use a macro to define how the DCB priority shall
behave at one place.
I think 1) is ugly. In the previous form, it also does not support
setting the property to "unset". We should implement properties as
types, and modify their behavior (by setting value_infos), instead
of implementing multiple, different types.
I slightly prefer 2b) over 2a) because it defines the behavior once,
but it's a bit harder to follow.
- Reduce duplicated code and implement the property according to
best-practice for integer types.
- Do not translate the output
- This way, the setter also supprts the nick names
In many cases we want to treat IPv4 and IPv6 generically. That looks nicer
if we distingish by an @addr_family integer, instead of a boolean.
Replace the @is_ipv6 boolean with an @addr_family paramter. The @is_ipv6
boolean is inconsistent with other places where we use @is_ipv4 to
indicate the opposite. Eventually, we should use @addr_family
everywhere.
Also, at the call site it's not immediately clear what TRUE/FALSE means,
here AF_INET/AF_INET6 is better.
- cleanup data type and use guint32 consistently. We might want to
introduce a new "infinity" value. But since libnm's
NM_SETTING_IP_CONFIG_DHCP_TIMEOUT asserts against the range
0 - G_MAXINT32, we cannot express it as -1 anyway. So, infinity
will have the numerical value G_MAXINT32, hence guint32 is just
fine.
- make use of existing ipv6.dhcp-timeout setting and add global
default configuration in NetworkManager.conf
- instead of having subclasses call nm_device_set_dhcp_timeout(),
add a virtual function get_dhcp_timeout().
A typo in the new dhcp-timeout option caused the dhclient daemon to exit
with error when the dhcp-timeout option was specified.
This prevents dhcp connection to be upped.
Fixes: 82ef497cc9
A newer compiler version might emit some warnings and break the build
of the RPM. Of course, such warnings must be fixed. But it is still very
inconvenient to break the build of an old RPM version without easy workaround.
When building without "test" (which is on by default), don't use fatal warnings
for compilation.
Previously when the interface created by pppd was already the one we
expected, we would rename it to itself and remove the device from the
manager. Don't do it.
Fixes: 6c3195931e
Remove NMDefaultRouteManager. Instead, add the default-route to the
NMIP4Config/NMIP6Config instance.
This basically reverts commit e8824f6a52.
We added NMDefaultRouteManager because we used the corresponding to `ip
route replace` when configuring routes. That would replace default-routes
on other interfaces so we needed a central manager to coordinate routes.
Now, we use the corresponding of `ip route append` to configure routes,
and each interface can configure routes indepdentently.
In NMDevice, when creating the default-route, ignore @auto_method for
external devices. We shall not touch these devices.
Especially the code in NMPolicy regarding selection of the best-device
seems wrong. It probably needs further adjustments in the future.
Especially get_best_ip_config() should be replaced, because this
distinction VPN vs. devices seems wrong to me.
Thereby, remove the @ignore_never_default argument. It was added by
commit bb75026004, I don't think it's
needed anymore.
This brings another change. Now that we track default-routes in
NMIP4Config/NMIP6Config, they are also exposed on D-Bus like regular
routes. I think that makes sense, but it is a change in behavior, as
previously such routes were not exposed there.
Default-routes are for the most part like regular routes. Add support to
track them like regular routes in NMIP4Config/NMIP6Config.
One thing is, sometimes we need to figure out whether an ip-config
instance has a default-route. For that, keep track of the best
default-route (there might be multiple) and expose it. That is
the most complicated part of this patch, because there are so many
places where the list of routes gets modified (replace, intersect,
subtract, merge, add), and they all need to take care of updating
the best default-route.
In a next patch, NMDefaultRouteManager will be dropped and default-routes
will be tracked by NMIP4Config/NMIP6Config.
Previously, we would first delete routes that are not to be added,
before adding the new ones.
This has the advantage, that even if delete removes the wrong route,
add would restore the expected state. This tries to workaround the fact
that RTM_DELROUTE allows for wild-card fields, and might delete the
wrong route.
However, for example when bumping the route metric after connectivty
check (removing the default-route with metric 20100 and adding the one
with metric 100), there is a short moment when there is no
default-route.
To avoid that, don't do delete-then-add, but add-then-delete.
Avoid calling nm_dedup_multi_index_add() directly, like we do for all other places.
Instead, call the wrapper _nm_ip_config_add_obj() which does some pre-precessing.
In practice, the result is exactly the same (at the moment). But there should by
only one way to add the route.
Don't rely on manager keeping them alive long enough. E.g.
get-best-device() is used when resetting the best device,
however, it accesses the current device (hence, it relies
on manager removing the device from the list, but keeping
it alive long enough).
We already track the best device as priv->default_device4 / priv->default_device6.
Don't try to look it up again. If the cached values from @priv are invalid/outdated,
that should be fixed instead.
This was already introduced by commit 773c006a4c.
But I don't think it should be done.
