The abbreviations "ns" and "ms" seem not very clear to me. Spell them
out to nsec/msec. Also, in parts we already used the longer abbreviations,
so it wasn't consistent.
Many device types take the MTU value from the wired setting; usually
they don't implement the can_reapply_change() method and so the MTU
can't be changed with the Reapply() API.
Instead of implementing the method for all such devices to support the
same property (adding a lot of duplicated code), add a check in
NMDevice to allow the reapply of MTU when we recognize that the device
uses the MTU from the wired setting.
Device types can still decide to implement can_reapply_change() and
support whatever properties they want, even from the wired setting.
If the activation of an assumed device fails, we first set the device
state to FAILED and then to ACTIVATED. In the FAILED state, the active
connection transitions to DEACTIVATED and clears its device pointer;
hence we end up with an inconsistent state which causes assertion
failures in other parts of the code (for example, get_best_ip_config()
assumes that the device of the best active connection is not NULL).
Don't first transition to FAILED and then to ACTIVATED, just set the
latter.
https://bugzilla.redhat.com/show_bug.cgi?id=1737774https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/351
Don't proceed if the context was torn down on an error in
try_create_connect_properties().
<info> [1574092292.0225] manager: NetworkManager state is now CONNECTING
<warn> [1574092292.0228] modem-broadband[ttyV0]: failed to connect 'ttyV0': unable to determine the network id
<info> [1574092292.0230] device (ttyV0): state change: prepare -> failed (reason 'modem-init-failed', sys-iface-state: 'managed')
<info> [1574092292.0236] manager: NetworkManager state is now DISCONNECTED
<warn> [1574092292.0250] device (ttyV0): Activation: failed for connection 'ttyV0'
(NetworkManager:69212): libnm-CRITICAL **: 16:51:32.025: ((libnm-core/nm-connection.c:193)): assertion '<dropped>' failed
Thread 1 "NetworkManager" received signal SIGTRAP, Trace/breakpoint trap.
0x00007ffff78da6e5 in _g_log_abort () from /lib64/libglib-2.0.so.0
(gdb) bt
#0 0x00007ffff78da6e5 in _g_log_abort () at /lib64/libglib-2.0.so.0
#1 0x00007ffff78db9b6 in g_logv () at /lib64/libglib-2.0.so.0
#2 0x00007ffff78dbb83 in g_log () at /lib64/libglib-2.0.so.0
#3 0x000055555563fcd2 in _nm_g_return_if_fail_warning (line=line@entry=193, file=0x5555557ae221 "libnm-core/nm-connection.c", log_domain=0x5555557ae23c "libnm") at ./shared/nm-default.h:219
#4 0x000055555563feba in _connection_get_setting_checkPython Exception <class 'gdb.error'> No type named TypeNode.:
(connection=0x0, setting_type=) at libnm-core/nm-connection.c:193
#5 _connection_get_setting_checkPython Exception <class 'gdb.error'> No type named TypeNode.:
(connection=0x0, setting_type=) at libnm-core/nm-connection.c:191
#6 0x00007fffe871f8b4 in nm_modem_get_connection_ip_type (self=self@entry=0x7fffd801c730, connection=0x0, error=error@entry=0x7fffffffc8e8) at src/devices/wwan/nm-modem.c:374
#7 0x00007fffe871bfed in connect_context_step (self=0x7fffd801c730) at src/devices/wwan/nm-modem-broadband.c:591
#8 0x00007fffe871c74b in modem_act_stage1_prepare (_self=0x7fffd801c730, connection=0x555555af5520, out_failure_reason=<optimized out>) at src/devices/wwan/nm-modem-broadband.c:687
#9 0x00007fffe8720203 in nm_modem_act_stage1_prepare (self=0x7fffd801c730, req=0x555555b08a30, out_failure_reason=0x7fffffffcbe0) at src/devices/wwan/nm-modem.c:1045
#10 0x0000555555705f1b in activate_stage1_device_prepare (self=0x555555a956a0) at src/devices/nm-device.c:6562
#11 0x00005555556dcbca in activation_source_handle_cb (self=0x555555a956a0, addr_family=2) at src/devices/nm-device.c:6177
#12 0x00007ffff78d0dcb in g_idle_dispatch () at /lib64/libglib-2.0.so.0
#13 0x00007ffff78d44a0 in g_main_context_dispatch () at /lib64/libglib-2.0.so.0
#14 0x00007ffff78d4830 in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0
#15 0x00007ffff78d4b23 in g_main_loop_run () at /lib64/libglib-2.0.so.0
#16 0x0000555555599ff4 in main (argc=<optimized out>, argv=<optimized out>) at src/main.c:451
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/338/
Add a new 'carrier' flag to the InterfaceFlags property of devices to
indicate the current carrier state.
The new flag is equivalent to the 'lower-up' flag for all devices
except the ones that use a non-standard carrier detection mechanism
like NMDeviceAdsl.
Add a new read-only "InterfaceFlags" property to the Device interface
to export via D-Bus kernel flags and possibly other NM specific
flags. At the moment IFF_UP and IFF_LOWERUP are implemented.
After we set link parameters (auto-negotiation, speed, duplex) in
stage1, the carrier can go down for several seconds because the
Ethernet PHY needs to renegotiate the link. Wait that carrier goes up
before starting the supplicant or the EAPoL start packet can be lost
causing an authentication failure.
https://bugzilla.redhat.com/show_bug.cgi?id=1759797
[user] are arbitrary strings that can be attached to a connection.
NetworkManager itself does not care about them, they are only here
for other applications.
Allow reapplying changes to the user setting. Usually the reason to
reject reapplying a setting is because it's either not implemented
or not possible to change (without a full reactivation of the device).
In this case there is nothing to implement, and of course it's possible
to do so.
In nm_acd_manager_announce_addresses() we should not only start the
probes but also add the acd file descriptor to the main loop.
Otherwise, a timer is armed to send the announcements but it never
fires and no announcements are sent.
Fixes: d9a4b59c18 ('acd: adapt NM code and build options')
https://bugzilla.redhat.com/show_bug.cgi?id=1767681
Track whether IP addresses were added by NM or externally. In this way
it becomes possible in a later commit to add prefix route only for
addresses added by NM.
Allow a reapply of the connection when the device is still activating
and ensure that each reapply action is performed only at a given
activation stage. For example, the IP configuration is not reactivated
if the device is in the prepare stage.
https://bugzilla.redhat.com/show_bug.cgi?id=1763062
If the 802.1X authentication fails and 802-1x.optional is set,
continue with activation. In this case, subscribe to the auth-state
supplicant property so that any dynamic IP method can be restarted
when the authentication succeeds. This is because upon authentication
the switch could have changed the VLAN we are connected to.
These "pending-actions" only have one purpose: to mark the device
as busy and thereby delay "startup complete" to be reached. That
in turn delays "NetworkManager-wait-online" service.
Of course, "NetworkManager-wait-online" waits for some form of readiness
and is not extensively configurable (e.g. you cannot exclude devices from
being waited). However, the intent is to wait that all devices are "settled".
That means among others, that the timeouts waiting for carrier and Wi-Fi scan
results passed, and devices either don't have a connection profile to autoactivate,
or they autoactivated profiles and are in state "connected".
A major point here is that the device is considered ready, once it
reaches the state "connected". Note that if you configure both IPv4 and
IPv6 addressing modes, than "ipv4.may-fail=yes" and "ipv6.may-fail=yes"
means, that the device is considered fully activated once one address
family completes. Again, this is not very configurable, but by setting
"ipv6.may-fail=no", you can require that the device has indeed IPv6
addressing completed.
Now, the determining factor for declaring "startup complete" is whether the
device is in state "connected". That may or may not mean that DHCPv4,
autoconf or DHCPv6 completed, as it depends on a overall state of the
device. So, it is wrong to have distinct pending actions for these operations.
Remove them.
This fixes that we wrongly would wait too long before declaring startup
complete. But it is also a change in behavior.
We try to set only one time the MTU from the connection to not
interfere with manual user changes.
If at some point the parent interface changes temporarily MTU to a
lower value (for example, because the connection was reactivated), the
kernel will also lower the MTU on child interface and we will not
update it ever again.
Add a workaround to this. If we detect that the MTU we want to set
from connection is higher that the allowed one, go into a state where
we follow the parent MTU until it is possible to set again the desired
MTU. This is a bit ugly, but I can't think of any nicer way to do it.
https://bugzilla.redhat.com/show_bug.cgi?id=1751079
A MACsec connection doesn't have an ordering dependency with its
parent connection and so it's possible that the parent gets activated
later and sets a greater MTU than the original one.
It is reasonable and useful to keep the MACsec MTU configured by
default as the maximum allowed by the parent interface, that is the
parent MTU minus the encapsulation overhead (32). The user can of
course override this by setting an explicit value in the
connection. We already do something similar for VLANs.
https://bugzilla.redhat.com/show_bug.cgi?id=1723690
Introduce a generic function to set a MTU based on parent's one. Also
define a device-specific @mtu_parent_delta value that specifies the
difference from parent MTU that should be set by default. For VLAN it
is zero but other interface types (for example MACsec) require a
positive value due to encapsulation overhead.
found by cppcheck
[src/devices/nm-device.c:3032] -> [src/devices/nm-device.c:3025]: (warning) Either the condition '!handle' is redundant or there is possible null pointer dereference: handle.
https://github.com/NetworkManager/NetworkManager/pull/352
The Bluetooth DUN device's NMModem would signal the reset of ifindex to zero
when it's disconnected and the NMDeviceBt would accordingly update the
bluetooth device's ip ifindex. This is not okay since commit ab4578302d
('device: refactor nm_device_set_ip_ifindex() and set_ip_iface()') which,
although claiming to be a refactoring, made such use of
nm_device_set_ip_ifindex() illegal. Resetting the ifindex is anyway not
necessary, since it's taken care of _cleanup_generic_post().
Let's leave the ifindex alone once the device is activated, in a manner
analogous to what NMDeviceModem.
Fixes: ab4578302d ('device: refactor nm_device_set_ip_ifindex() and set_ip_iface()')
Fixes: 78ca2a70c7 ('device: don't set invalid ip-iface'):
The devices tests' meson build files include only the build of a
single executable file and its execution as a test unit.
This has been moved to the devices' main meson build files so this
files can be removed.
In 878d4963e a new `nm-bt-test` helper program was added. However,
although `autotools` build steps were included, meson build steps
were not.
This add meson's build steps.
The test unit name string is used in different place so it has been
replaced by a variable.
The `nm-service-providers.c` source file is appended by using a
`files` generated object.
