- add assert code to check that our internal tracking of
the gateways is consistent.
- assert (gracefully) against libndp returning :: as gateway
address.
We encounter the same enum in 3 forms:
- NMNDiscPreference in NetworkManager
- "enum ndp_route_preference" in <ndp.h>
- ICMPV6_ROUTER_PREF_* in <linux/icmpv6.h>
Move our enum to nm-core-utils.h, so that it can be used
by platform code as well (platform code should not include
ndisc/nm-ndisc.h).
Also, NMNDiscPreference was not numerically identical to their
native values (meaning: it shuffled the names and numbers).
Make them all numerically equal, so that they can be used in
the same context.
This means, while previously we could compare NMNDiscPreference
directly according to their priority, we now need _preference_to_priority().
On the other hand, we could omit translate_preference() -- but actually,
we still have _route_preference_coerce() because pref comes from libndp
and is thus untrusted. We still have to range check it.
We have the timestamp nm_utils_get_monotonic_time_s(), which should be
gint32 type. Then we also have timestamps in the NMNDisc* objects, which
consist of guint32 timestamp and lifetime.
Cleanup handling the times and calculation of the timestamps by using
the correct integer type consistently and ensuring that no integer overflow
occurs.
The @i variable to loop over the arrays should have the same type as
GArray.len, to which it is compared. In this case "guint".
As we remove items from the arrays while iterating over it, it gets
a bit complicated either way. I disliked that
g_array_remove_index (rdata->gateways, i--);
would underflow for unsigned integers. While that would work fine,
I think that is confusing. So, the variable is no longer incremented
in the increment statement of the for loop.
The bus manager takes extra references to the GDBusConnection every
time g_dbus_object_manager_server_get_connection() its called,
preventing its disposal once the connection is closed. This causes a
leak for each DHCP event.
https://bugzilla.redhat.com/show_bug.cgi?id=1461643
When adding a new Wi-Fi connection, nmtui crashes.
Usually, a verified Wi-Fi connection always has key_mgnt set.
However, the client doesn't have the luxury to assume that all
connections verify. Especially, while creating a new connection.
#0 0x00007ffff4fe5baa in __strcmp_sse2_unaligned () at ../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S:31
#1 0x000055555556654c in get_security_type (binding=0x5555557d1cf0) at clients/tui/nm-editor-bindings.c:591
#2 0x000055555556593b in wireless_security_changed (object=0x0, pspec=0x0, user_data=0x5555557d1cf0) at clients/tui/nm-editor-bindings.c:628
#3 0x000055555556536d in nm_editor_bind_wireless_security_method (connection=0x5555558028e0, s_wsec=0x555555892eb0 [NMSettingWirelessSecurity], target=0x555555935e10, target_property=0x55555559311b "active-id", flags=(G_BINDING_BIDIRECTIONAL | G_BINDING_SYNC_CREATE)) at clients/tui/nm-editor-bindings.c:796
#4 0x000055555557a3aa in nmt_page_wifi_constructed (object=0x5555559349e0 [NmtPageWifi]) at clients/tui/nmt-page-wifi.c:338
#5 0x00007ffff5e6b670 in g_object_new_internal (class=class@entry=0x5555557c14c0, params=params@entry=0x7fffffffc440, n_params=n_params@entry=2) at gobject.c:1823
#6 0x00007ffff5e6d24d in g_object_new_valist (object_type=object_type@entry=93824994775616, first_property_name=first_property_name@entry=0x5555555920c6 "connection", var_args=var_args@entry=0x7fffffffc590) at gobject.c:2042
#7 0x00007ffff5e6d691 in g_object_new (object_type=93824994775616, first_property_name=0x5555555920c6 "connection") at gobject.c:1626
#8 0x000055555557985a in nmt_page_wifi_new (conn=0x5555558028e0, deventry=0x5555557d15e0 [NmtDeviceEntry]) at clients/tui/nmt-page-wifi.c:45
#9 0x000055555556f7e2 in nmt_editor_constructed (object=0x555555922af0 [NmtEditor]) at clients/tui/nmt-editor.c:374
#10 0x00007ffff5e6b670 in g_object_new_internal (class=class@entry=0x555555932750, params=params@entry=0x7fffffffcac0, n_params=n_params@entry=4) at gobject.c:1823
#11 0x00007ffff5e6d24d in g_object_new_valist (object_type=object_type@entry=93824996288016, first_property_name=first_property_name@entry=0x5555555920c6 "connection", var_args=var_args@entry=0x7fffffffcc10) at gobject.c:2042
#12 0x00007ffff5e6d691 in g_object_new (object_type=93824996288016, first_property_name=0x5555555920c6 "connection") at gobject.c:1626
#13 0x000055555556f261 in nmt_editor_new (connection=0x555555802880) at clients/tui/nmt-editor.c:109
#14 0x0000555555562b35 in nmt_edit_connection (connection=0x555555802880) at clients/tui/nmtui-edit.c:448
#15 0x0000555555563a29 in create_connection (widget=0x55555588b150 [NmtNewtListbox], list=0x555555922a00) at clients/tui/nmtui-edit.c:185
#16 0x0000555555563a5d in create_connection_and_quit (widget=0x55555588b150 [NmtNewtListbox], list=0x555555922a00) at clients/tui/nmtui-edit.c:192
#20 0x00007ffff5e81b0f in <emit signal ??? on instance 0x55555588b150 [NmtNewtListbox]> (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>) at gsignal.c:3447
#17 0x00007ffff5e6630d in g_closure_invoke (closure=0x555555929260, return_value=0x0, n_param_values=1, param_values=0x7fffffffcfe0, invocation_hint=0x7fffffffcf60) at gclosure.c:804
#18 0x00007ffff5e7898e in signal_emit_unlocked_R (node=node@entry=0x55555582ac70, detail=detail@entry=0, instance=instance@entry=0x55555588b150, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7fffffffcfe0) at gsignal.c:3635
#19 0x00007ffff5e811a5 in g_signal_emit_valist (instance=0x55555588b150, signal_id=<optimized out>, detail=0, var_args=var_args@entry=0x7fffffffd1b0) at gsignal.c:3391
#21 0x000055555558e43f in nmt_newt_widget_activated (widget=0x55555588b150 [NmtNewtListbox]) at clients/tui/newt/nmt-newt-widget.c:329
#22 0x0000555555584fc8 in nmt_newt_form_iterate (form=0x555555922a00 [NmtAddConnection]) at clients/tui/newt/nmt-newt-form.c:309
#23 0x0000555555585d62 in nmt_newt_form_keypress_callback (fd=1435623072, condition=G_IO_IN, user_data=0x0) at clients/tui/newt/nmt-newt-form.c:335
#24 0x00007ffff598a247 in g_main_dispatch (context=0x5555557c3af0) at gmain.c:3234
#25 0x00007ffff598a247 in g_main_context_dispatch (context=context@entry=0x5555557c3af0) at gmain.c:3899
#26 0x00007ffff598a5e8 in g_main_context_iterate (context=0x5555557c3af0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3972
#27 0x00007ffff598a902 in g_main_loop_run (loop=0x55555591b190) at gmain.c:4168
#28 0x00005555555609b5 in main (argc=1, argv=0x7fffffffd5e8) at clients/tui/nmtui.c:298
Fixes: 6a4af482f0
Before commit 650a7022c1, we would
always forego using getrandom(). That changed, and now we detect
at compile time whether getrandom() is provided by libc. So, if you
build against recent libc, we use it too.
However, systemd's src/basic/missing_syscall.h also provides getrandom() by
calling the syscall directly. We don't do that, because it seems too cumbersome
to maintain.
Fixes: 650a7022c1
Extend policy-routing and replace previously added route-table-sync
setting with a route-table setting. The route table can now be
configured per connection profile and affects all routes.
This branch breaks API/ABI on development branch by dropping
ipv4.route-table-sync from libnm.
https://bugzilla.redhat.com/show_bug.cgi?id=1436531
Instead of having 3 properties @gateway, @never_default and @has_gateway
on NMIP4Config/NMIP6Config that determine the default-route, track the
default-route as a regular route.
The gateway setting is the configuration knob for the default-route.
Since an NMIP4Config/NMIP6Config instance only has one gateway property,
it cannot track more then one default-routes (see related bug rh#1445417).
Especially with policy routing, it might be interesting to configure a
default-route in multiple tables.
Also, later it might be interesting to allow adding default-routes as
regular static routes in a connection, so that the user can configure additional
route parameters for the default-route or add default-routes in multiple tables.
With this patch, default-routes now have a rt_source property according to their
origin.
Also, the previous commits of this branch broke handling of the
default-route :) . That should be working now again.
It's not needed. Whenever we add a route, we pass in the
route metric (for example, based on the device's configuration).
No need to merge and track it into the NMIP4Config/NMIP6Config.
The metric was only used in nm_ip4_config_create_setting()
and nm_ip6_config_create_setting(). In fact it's wrong to do
that, because it means we first capture some settings, and guess
the configured route metric. But we cannot do that. Our best
guess what a configured setting might be is -1.
The MSS is only set for VPN connections (by merging it in the respective
NMIP4Config/NMIP6Config).
It is also only used when setting the MSS of the default route.
Don't track that property in NMIP4Config/NMIP6Config, instead, set the
mss of the route directly in nm_vpn_connection_ip4_config_get() and
nm_vpn_connection_ip6_config_get().
There is a potential change in behavior here: NMDevice also consisdered
the MSS for the default route, but that would only be set if the MSS
gets merged from an vpn-ip-config. Which at most is the case for
iterface-less VPN types (libreswan). But even in that case, it doesn't
seem right to me to use the VPN's MSS for the device's default-route.
We added "ipv4.route-table-sync" and "ipv6.route-table-sync" to not change
behavior for users that configured policy routing outside of NetworkManager,
for example, via a dispatcher script. Users had to explicitly opt-in
for NetworkManager to fully manage all routing tables.
These settings were awkward. Replace them with new settings "ipv4.route-table"
and "ipv6.route-table". Note that this commit breaks API/ABI on the unstable
development branch by removing recently added API.
As before, a connection will have no route-table set by default. This
has the meaning that policy-routing is not enabled and only the main table
will be fully synced. Once the user sets a table, we recognize that and
NetworkManager manages all routing tables.
The new route-table setting has other important uses: analog to
"ipv4.route-metric", it is the default that applies to all routes.
Currently it only works for static routes, not DHCP, SLAAC,
default-route, etc. That will be implemented later.
For static routes, each route still can explicitly set a table, and
overwrite the per-connection setting in "ipv4.route-table" and
"ipv6.route-table".
- merge the IPv4 and IPv6 implementations. They are for the most
part identical. Also, they are independent of NMIP4Config/NMIP6Config.
- parse the entire file at once. Don't parse it twice, once for the
name servers and once for the options. This also avoids loading
/etc/resolv.conf twice, as it would be done before.
These static variables really never be modified.
Mark them as const, which allows the linker to mark them as
read-only.
The problem is libnl3's API, which has these parameters
not as const. Add a workaround for that. Clearly libnl3 is
not gonna modify the policy, that the API was fixed too [1]
[1] b4802a17a7
The line
device (wlan0): state change: ip-config -> ip-check (reason none, internal state managed)
prints the sys-iface-state, which is at other places logged with
device[0x55914506ed70] (wlan0): sys-iface-state: external -> managed
For consistency, name the same parameter the same.
The name "priority" is well established for routes (e.g. kernel's
RTA_PRIORITY netlink attribute).
However, we call it at most places "metric" or "route_metric".
Rename it, not to use two different names for the same thing.
The name nm_device_get_priority() is misleading. Nowadays it's only used
for the default route metric, and nothing else.
Rename it, and make it static.
One might already question the existance of nm_utils_parse_inaddr_bin(),
because it only wraps inet_pton(), which by itself isn't terrible API.
The reason nm_utils_parse_inaddr_bin() exists, is to mirror to nm_utils_parse_inaddr()
function, which has additional functionality on top of inet_pton().
But we shouldn't have more then one wrapper for inet_pton().
For some logging lines this changes the domain
from LOGD_PPP or LOGD_MB|LOGD_IP4 to LOGD_MB.
Also, it changes the format of the prefix, and
adds a prefix for some logging lines that didn't
have one previously.
We already have nm_strquote_a(). That is useful, but uses alloca(), hence it
is ill suited to be called from a macro, inside a loop, or from a function
that should be inlined.
Instead, add nm_strquote() that has the same purpose but writes to a provided
string buffer.
gcc doesn't consider variables with cleanup attribute as unused.
clang does, and warns about them.
In one case, clang is right, in the other one the warning is bogus.
Fix both.
Found by clang warning:
src/devices/nm-device.c:11370:14: error: use of logical '||' with constant operand [-Werror,-Wconstant-logical-operand]
|| NM_UNMANAGED_USER_UDEV
^ ~~~~~~~~~~~~~~~~~~~~~~
Fixes: 5778bc6a34
