A better name is link_speed_update(), because it re-reads and
sets the speed value.
Also, move _notfiy() after logging. It doesn't matter in this
case, but we should first log, and then do actions that have potentially
complex side-effects.
Now, that NMDeviceClass:carrier_changed_notify() is no longer called as
deferred action, we can check for DCB state there, instead or registering
to the NM_DEVICE_CARRIER notifications.
Note that:
- carrier_changed_notify() has only one implementation: NMDeviceEthernet
to call get_link_speed() when carrier comes back.
- currently, calling carrier_changed_notify() with carrier=FALSE
has no effect, because NMDeviceEthernet only acts on carrier=TRUE.
- when carrier appears, nm_device_set_carrier() will call
carrier_changed() right away. We only call carrier_changed()
with carrier=TRUE only at one place. The change merley moves
carrier_changed_notify() out of the function. Apart from
that it has no effect.
- when carrier disappears, previoulsy we would delay action for
4 seconds. Hence, we would delay carrier_changed_notify() as well
-- although it has no effect.
The last point is at least ugly. Fix it by moving
carrier_changed_notify() to nm_device_set_carrier().
Coverity complains about not checking the return value:
src/settings/nm-settings-connection.c:2329: check_return: Calling "g_key_file_load_from_file" without checking return value (as is done elsewhere 6 out of 7 times).
While at it, refactor the code and check whether the timestamp
is valid.
NetworkManager-1.8.0/src/supplicant/nm-supplicant-interface.c:232: check_return: Calling "g_async_initable_init_finish" without checking return value (as is done elsewhere 7 out of 8 times).
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.
