- no need to call nm_platform_process_events() after
nmtstp_wait_for_signal(). The latter processes all events
that are pending.
- with addr_n number of addresses, we still only want to wait
a maximum time, not for each addresss individually. Basically,
the for-loop must be inside NMTST_WAIT(), not the other way around.
Having an unsigned "guint timeout_ms" argument is very inconvenient, because
nmtstp_wait_for_signal (NM_PLATFORM_GET (), end_time - now_time);
might easily be negative. In such a case, the correct behavior
is to wait not at all.
The previous behavior, of treating timeout_ms as *no timeout*, makes
no sense. At least not for unit tests. If you have a really long timeout,
then set it. "0" should really mean to schedule a zero timeout.
when adding a route with RTA_PREFSRC some kernel versions will reject
the request if the specified source address is still tentative: be sure
that the just added addresses are no more tentative before adding the
routes.
There are a lot of places where we want to either write a number,
or conditionally clear it. Like:
mtu = nm_setting_wireless_get_mtu (s_wireless);
if (mtu)
svSetValueInt64 (ifcfg, "MTU", mtu);
else
svUnsetValue (ifcfg, "MTU");
To support legacy scripts, we want to write out the NETMASK
key whenever the ifcfg file has a NETMASK key previously.
Note, that we anyway always write the relevant PREFIX key.
The NETMASK is redundant, only there to help legacy scripts.
That was broken, because we would svUnsetValue("NETMASK") before
checking whether the NETMASK key is present.
Also, when saving a connection to ifcfg-rh file that was created
by other tools, we might mix up the numbering. E.g. we never
write out IPADDR0. Hence, turn on legacy mode whenever the ifcfg-rh
file has any key starting with "NETMASK".
Change behavior for the network-address and broadcast-address.
Users should not specify such addresses, but if they do, generate
something more sensible.
Also, if the address was in network larger then /24, the
generated address range was rather unexpected. Change behavior
here.
There are no particularly strong reasons for the chosen range.
It just seems suitable. The decision to hand out at most a /24
is because it is likely to be plenty, and because that is what
the previous code did -- at least, if the address was in the
first /24 of the subnet. See how the result for 192.168.0.1/20
is unchanged, but 192.168.1.1/20 changes.
Changes:
- merge reserve_shared_ip() into shared4_new_config().
shared4_new_config() needs to register release_shared_ip(). However, it
wrongly would always register release_shared_ip(), even for user-supplied
addresses. To fix that, we would need yet another argument to
reserve_shared_ip() and coupling it even more with shared4_new_config().
At that point, it's cleaner to just merge the two functions.
- only create the shared_ips hash when needed, and delete it when
it's empty. The idea is, that NetworkManager possibly runs for a long
time, and most of the time no shared connection is active. Just clean
up the empty hash while we don't need it.
nmtstp_env1_add_test_func() allows to register test functions in a
particular test environment ("env1", for lack of a better name).
It will be reused for "test-route.c"
Otherwise a device which was set as unmanaged (updated to the REMOVED
internal sys-state) will never update its own sys-state if later set
back as managed.
Manage either when setting explictly the device to managed either when
just upping a connection on an unmanaged device.
Commits 39d0559d9a ("platform: sort links by name instead of
ifindex") and 529a0a1a7f ("manager: sort slaves to be autoconnected
by device name") changed the order of activation of slaves. Introduce
a system-wide configuration property to preserve the old behavior.
https://bugzilla.redhat.com/show_bug.cgi?id=1452585
With address sanitizer, the call to setrlimit() fails by default,
because the core dump would be huge. That could be overwritten via
ASAN_OPTIONS=disable_core=0
But just don't try to enable core-dumps with asan.
On cleanup, unconditionally release a device from its master if the
link is missing or it doesn't have a master, otherwise the master
would later try to release the slave, hitting the following assertion:
"nm_platform_link_release: assertion 'slave > 0' failed"
#0 g_logv
#1 g_log
#2 g_return_if_fail_warning
#3 nm_platform_link_release
#4 release_slave
#5 nm_device_master_release_one_slave
#6 slave_state_changed
#7 ffi_call_unix64
#8 ffi_call
#9 g_cclosure_marshal_generic
#10 g_closure_invoke
#11 signal_emit_unlocked_R
#12 g_signal_emit_valist
#14 _set_state_full
#15 nm_device_state_changed
#16 nm_device_unrealize
#17 _platform_link_cb_idle
#18 g_main_context_dispatch
#19 g_main_context_dispatch
#20 g_main_context_iterate
#21 g_main_loop_run
#22 main
Fixes: 9e8218f99ahttps://bugzilla.redhat.com/show_bug.cgi?id=1448907
Use nm_device_get_ip_ifindex() to obtain the right ifindex for the
device. Fixes the following:
nm_platform_ip4_address_get_all: assertion 'ifindex > 0' failed
#0 _g_log_abort () from target:/lib64/libglib-2.0.so.0
#1 g_logv () from target:/lib64/libglib-2.0.so.0
#2 g_log () from target:/lib64/libglib-2.0.so.0
#3 nm_platform_ip4_address_get_all (self=self@entry=0x1181020, ifindex=ifindex@entry=0) at src/platform/nm-platform.c:2640
#4 nm_ip4_config_capture (platform=0x1181020, ifindex=ifindex@entry=0, capture_resolv_conf=capture_resolv_conf@entry=0) at src/nm-ip4-config.c:271
#5 ip4_config_merge_and_apply (self=self@entry=0x1254a70, config=config@entry=0x0, commit=commit@entry=1) at src/devices/nm-device.c:5447
#6 activate_stage5_ip4_config_commit (self=0x1254a70) at src/devices/nm-device.c:8299
#7 activation_source_handle_cb (self=0x1254a70, family=family@entry=2) at src/devices/nm-device.c:4421
#8 activation_source_handle_cb4 (user_data=<optimized out>) at src/devices/nm-device.c:4358
#9 g_idle_dispatch () from target:/lib64/libglib-2.0.so.0
#10 g_main_context_dispatch () from target:/lib64/libglib-2.0.so.0
#11 g_main_context_iterate.isra () from target:/lib64/libglib-2.0.so.0
#12 g_main_loop_run () from target:/lib64/libglib-2.0.so.0
#13 main (argc=<optimized out>, argv=<optimized out>) at src/main.c:435
Fixes: a21b8882cc
g_variant_new_parsed() returns a floating reference. Later, we pass
the floating reference to nm_settings_connection_new_secrets(),
but don't transfer ownership.
That might not be a bug (I didn't check), but it requires that
nm_settings_connection_new_secrets() does not take a reference
to the secrets variant.
Convert the floating reference to a real reference to avoid
this dangerous pattern.
Fixes: 0eb7617504
We pack the PSK byte array in a GVariant of type string,
hence all characters must be valid UTF-8.
Maybe we should do something more sophisticated but let's
just ignore such pass phrases.
Fixes: 0eb7617504
with the rework in commit #87a3df2e572ed47b5f76f6d1cad63ce622296e21
the check of the return value of _device_activate () is no more needed.
Remove useless check and var.
ip link add name $'d\xccf\\c' type dummy
Use nm_utils_str_utf8safe_escape() to sanitize non UTF-8 sequences
before exposing them on D-Bus. The operation can be reverted client
side via nm_utils_str_utf8safe_unescape() or simply g_strcompress().
Note that this preserves all valid UTF-8 sequences as-is, with exception
of the backslash escape character and ASCII control characters. Thus, this
is a change in behavior for strings that contain such characters.
Note that nmcli is not changed to somehow unescape the string before
printing. As the string is not valid UTF-8 (or contains ASCII characters
that need escaping), they are not printable as-is, so unescaping before
printing makes little sense.
If the platform signaled that the external configuration changed (and
thus update_ipX_config() is scheduled) and we are doing a commit of
the new configuration, update priv->ext_ipX_config. Without this, the
commit will remove addresses added externally but not yet captured in
the external configuration.
https://bugzilla.redhat.com/show_bug.cgi?id=1449873
This basically reverts commit 31fe84e467 "core: Add host route for
DHCP4 server if outside assigned subnet (bgo #721767)" because the
additional route added by NM does more harm than good.
First, the code does not consider routes pushed by the server and thus
it can add a route conflicting with the ones from the network
administrator.
Second, there is no specification on what a DHCP client should do when
the server is not reachable via unicast, and adding arbitrary logic
into the client is likely to break things in specific cases. If
network administrators want to make the DHCP server reachable from a
client in a different subnet, they should push proper routes with the
lease.
In any case, if the DHCP server is not reachable through unicast,
before the lease expiration (after timeout T2) the client will resort
to broadcast and so there won't be any network disruption; the renewal
will only happen at a later time.
Fixes: 31fe84e467https://bugzilla.redhat.com/show_bug.cgi?id=1448987
