NetworkManager-1.8.0/src/supplicant/tests/test-supplicant-config.c:528: check_return: Calling "nm_setting_802_1x_set_ca_cert" without checking return value (as is done elsewhere 13 out of 16 times).
commit a955639 (connectivity: don't do periodic checks on interval=0)
broke scheduling connectivity checks.
That is because the timer is on only scheduled if
nm_connectivity_check_enabled(), which in turn only returns TRUE
if curl_mhandle is set. However, nm_connectivity_init() would only
initialize curl_mhandle after update_config(), missing to schedule
the periodic task.
https://mail.gnome.org/archives/networkmanager-list/2017-May/msg00076.html
Fixes: a95563996f
rpmdiff complains about uses of inet_aton, inet_makeaddr, inet_netof,
inet_ntoa under the IPv6 section:
usr/sbin/NetworkManager on aarch64 i686 x86_64 ppc ppc64 ppc64le s390 s390x uses function inet_aton, which may impact IPv6 support
I think the warning is bogus, but refactor our code to avoid it.
Note that systemd code still uses them, so it don't avoid the rpmdiff
warning. But let's not diverge our systemd import from upstream for this.
- for NMSettingBond:validate_ip() also avoid g_strsplit_set() which
allocates a full strv. Instead, we can do with one g_strdup().
- for test-resolvconf-capture.c, replace the functions with macros.
Macros should be avoided usually, but for test asserts they are
more convenient as they preserved the __FILE__:__LINE__ of where
the assertion fails.
Teamd is not happy about them and would fail anyway. Worse even, if we
json_loads() such a JSON, which is precisely what happens when we inject the
"hwaddr" key, we turn bad JSON into a good one in a lossy matter. Not good.
https://bugzilla.redhat.com/show_bug.cgi?id=1455130
If there is value in such a helper function (there is), then
it should go alongside the other nm_connection_get_setting*()
helpers. NMDevice is already large enough.
The plugins may use stuff from core, but not the other way around.
Including "bluetooth/nm-bluez-common.h" is wrong.
The UUID argument is always "nap" in the NAP case. We don't need
the flexibility that it might be anything else. Just drop it.
As far as NMDevice is concerned, it anyway wouldn't (or shouldn't
know what the uuid is. It says register, and NMBluez5Manager should
figure out the details.
We'll use this to let the devices know they can retry autoactivation
because some component became available without actually having any
data that would be useful for that device.
Adjust the comment.
- 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
