VPN connections always return true for nm_connection_need_secrets(), but the
documented behavior of GetSecrets() is just to return any secrets we have
(otherwise nmcli c --show-secrets would not be useful for VPN connections).
Since f32075d2fc, we remove the kernel
added IPv4 device route, and re-add it with appropriate metric.
This could potentially replace existing, conflicting routes. Be more
careful and only take any action when we don't have a conflicting
route and when we add the address for the first time.
The motivation for this was libreswan which might install a VPN route
for a subnet that we also have configured on an interface. But the route
conflict could happen easily for other reasons, for example if you
configure a conflicting route manually.
Don't replace the device route if we have any indication that
a conflict could arise.
https://bugzilla.gnome.org/show_bug.cgi?id=723178
Coverity:
Defect type: CONSTANT_EXPRESSION_RESULT
/src/NetworkManagerUtils.c:726: result_independent_of_operands: "18446744073709551615UL /* 9223372036854775807L * 2UL + 1UL */ < (gulong)sleep_duration_msec * 1000UL" is always false regardless of the values of its operands. This occurs as the logical first operand of '?:'.
because either GSM or CDMA is present. It is checked just above.
Coverity:
Defect type: DEADCODE
src/devices/bluetooth/nm-device-bt.c:312: dead_error_line: Execution cannot reach this statement: "fallback_prefix = dcgettext...".
Coverity:
Defect type: UNINIT
src/NetworkManagerUtils.c:1906: uninit_use_in_call: Using uninitialized value "tp.tv_nsec" when calling "monotonic_timestamp_get".
src/NetworkManagerUtils.c:1879: uninit_use_in_call: Using uninitialized value "tp.tv_nsec" when calling "monotonic_timestamp_get".
src/NetworkManagerUtils.c:1852: uninit_use_in_call: Using uninitialized value "tp.tv_nsec" when calling "monotonic_timestamp_get".
src/NetworkManagerUtils.c:1825: uninit_use_in_call: Using uninitialized value "tp.tv_nsec" when calling "monotonic_timestamp_get".
Coverity:
Defect type: CONSTANT_EXPRESSION_RESULT
src/NetworkManagerUtils.c:1978: same_on_both_sides: "(v1->diff_result & NM_SETTING_DIFF_RESULT_IN_B) != (v1->diff_result & NM_SETTING_DIFF_RESULT_IN_B)" is always false regardless of the values of its operands because those operands are identical. This occurs as the logical operand of if.
In several cases, connection uuids are generated based on
some strings. Change the algorithm, to prefix the hashed
identifier differently for each setting type. This makes
collisions very unlikely.
Also, change the algorithm, to create proper Variant3 UUIDs.
This is a behavioral change, but it only affects code places
that were added since nm-0-9-10 and were not yet part of
a stable release.
There are different types (variants) of UUIDs defined.
Especially variants 3 and 5 are name based variants (rfc4122).
The way we create our UUIDs in nm_utils_uuid_generate_from_string()
however does not create them according to RFC and does not set
the flags to indicate the variant.
Modify the signature of nm_utils_uuid_generate_from_string() to accept
a "uuid_type" argument, so that we later can add other algorithms without
breaking API.
nm_device_removed() calls nm_device_release_one_slave() in order to
fix up NetworkManager's master/slave bookkeeping, but we don't want to
tell the kernel to actually unslave the device, since that would
happen automatically anyway if the device was really removed, and
shouldn't happen if the device is just being removed from NM's device
list.
(In particular, don't remove all libvirt-created virtual network
devices from virbr0 when NetworkManager exits.)
nm_device_get_hw_address() may return NULL and nm_platform_link_get_type may
return NM_LINK_TYPE_NONE. While it might be a good idea to check for such cases
at the init time it seems easier to just ignore it and prevent blowing up in
subsequent deactivation.
A quick test case:
# while :; do ip link add moo0 type veth peer moo1; ip link del moo0 ; done
Yields:
NetworkManager:ERROR:devices/nm-device-ethernet.c:268:constructor:
assertion failed: (link_type == NM_LINK_TYPE_ETHERNET ||
link_type == NM_LINK_TYPE_VETH)
nm_device_set_hw_addr: assertion 'addr != NULL' failed
https://bugzilla.gnome.org/show_bug.cgi?id=740992
For IPv4, iproute for example defaults to a metric of 0.
Hence, the name NM_PLATFORM_ROUTE_METRIC_DEFAULT was misleading.
Also add a NM_PLATFORM_ROUTE_METRIC_DEFAULT_IP4 define for completeness.
https://bugzilla.gnome.org/show_bug.cgi?id=740780
We recently changed default values for route metrics. Revise that
again and increase the space between the default values.
No strong reason to do this, but it seems better to have larger
gaps and make use of the available range.
The parent device is just the device that happens to be the best device.
It does not mean, that its route metric should be inherited to the VPN
connection.
This also makes the resulting route metric for VPN connections much
more predictable: now it is either ipv4.route-metric from the connection,
or it falls back to NM_VPN_ROUTE_METRIC_DEFAULT (10).
Also read the command line argument as G_OPTION_ARG_INT64 type. Otherwise, on
32-bit integers, you could not enter any number larger then G_MAXINT32.
Signed-off-by: Thomas Haller <thaller@redhat.com>
For IPv4 addresses, the kernel automatically adds a route when
configuring an IP address. Unfortunately, there is no way to control
this behavior or to set the route metric.
Fix this, by adding our own route and removing the kernel provided
one.
Note that this adds a major change in that we no longer call
nm_ip4_config_commit() for assumed devices.
https://bugzilla.gnome.org/show_bug.cgi?id=723178
Signed-off-by: Thomas Haller <thaller@redhat.com>
NMIPRoute is used by NMSettingIPConfig, but also
NMIPConfig. In the former case, default routes are (still)
disallowed. But in the NMIPConfig use-case, it can make sense
to expose default routes as NMIPRoute instances.
Relax the restriction on the NMIPRoute API to allow this
future change.
No code actually supports having NMIPRoute instances with
prefix length zero (default routes). Up to now, all such uses
would be a bug.
https://bugzilla.gnome.org/show_bug.cgi?id=739969
Signed-off-by: Thomas Haller <thaller@redhat.com>
The previous nm-dhcp-systemd code for logging the lease expiry time,
and exporting that value to D-Bus was clamping the value to
G_MAXUINT32-1, but that's unnecessary on x86_64, and incorrect on x86
(since time_t is signed).
Correctly adding a value to the current time and not overflowing seems
to be more-or-less impossible without having separate cases for 4- and
8-byte time_t. Since this was basically just for logging purposes
anyway, just log the number of seconds rather than the timestamp, and
then we don't have to worry about sizeof(time_t).
We've previously been just watching for state changes into UNMANAGED state. No
state change is emitted upon removal of a device which is already unmanaged.
https://bugzilla.gnome.org/show_bug.cgi?id=737659
Before, we would only track a device in NMDefaultRouteManager
if it had a default route. Otherwise the entry for the device
was removed.
That was wrong, because having no entry meant that the interface
is assumed and hence we would not touch the interface. Instead we must
esplicitly track devices without default route to know when an interface
has no default route.
Signed-off-by: Thomas Haller <thaller@redhat.com>
It's better to add the more important routes first. Otherwise there
might be a short time when a lower priority route has precedence.
Signed-off-by: Thomas Haller <thaller@redhat.com>
The previous commit made NM enforce the default route on interfaces for
which NM manages a default route.
For interfaces that are configured never-default, NM will now pick up
any externally configured default route, as if it was managed by NM.
This is important, because NMDefaultRouteManager needs a notion of which
is the best device. Without this change, it was agnostic to default routes
on managed, never-default interfaces.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Monitor default routes from platform, and resync the default routes
on changes.
For one, this fixes the following use-case: have an assumed device em1
with two routes of metric 20 and 21. Activate em2, which will get effective
metric 22.
When externally removing route em1/20, em2 would resync the effective metric to
20. This is correct and already worked before. However, when deleting em1/21,
nothing happened. With this change, em2 would resync to metric 21 to fill the gap.
However this commit has much bigger effects: whenever the user externally adds
a default route to an interface for which NM manages an default route, NM will
delete it.
Also, when deleting the default route (managed by NM), NM would readd
it. Effectivly, the user can no longer mess with the default route on
interfaces for which it manages the default route.
If the connection is configured never-default, the user still can add
default routes and NM will not touch them.
Obviously, this has no effect for assumed devices either and the user
can externally add and remove default routes as he wishes.
https://bugzilla.gnome.org/show_bug.cgi?id=735512
Signed-off-by: Thomas Haller <thaller@redhat.com>
Don't only consider the best route of assumed devices when syncing the route
metrics. This fixes the following scenario:
Have em1 assumed, with two default routes (metric 20 and 21).
When activating em2, NMDefaultRouteManager would have determined
21 as the effective metric, thus replacing the assumed route of em1.
Since we don't want to touch assumed interfaces, it is wrong to
replace their default routes.
Instead, keep track of all the assumed default routes and consider their
metrics when choosing effective_metric.
Signed-off-by: Thomas Haller <thaller@redhat.com>
When calling update_default_route(), NMDefaultRouteManager will look at the
source, and determine whether it has a default route or not. For example
for device sources, this means calling nm_device_get_ip4_default_route().
If the source indicates that it has no default route, the effect of
calling update_default_route() is the same as calling
remove_default_route() (hence, remove() can be replaced by update()).
If the source however still indicates a default route, the behavior
would be different. This case would be an undesired inconsistancy,
because source and NMDefaultRouteManager would disagree of whether
the source has a default route.
Source must always properly indicate whether it has a default route
or not, hence this situation does not arise.
Hence it is always better to call update().
Signed-off-by: Thomas Haller <thaller@redhat.com>
The case of having a metric MAXUINT32 is special, because in face of
multiple default routes with the same metric, NMDefaultRouteManager
cannot reduce the effective metric (because there is no lower priority
value).
This case works already correct, just when adding such a default route,
ensure that we add it to the *first* entry.
Signed-off-by: Thomas Haller <thaller@redhat.com>
