I think it's technically not correct to rely on the "sentinal" field
being immediately after the previous field, due to alignment. Implement
the macro differently.
Add a 'in-state-change' pending action to be sure the device always has a
pending when transitioning between states (this prevents callbacks to mark
startup as complete while running _set_state_full()).
This is needed as during the 'failed'->'disconnected' the pending action 'activation-*'
for the device is removed resulting in an empty pending_actions list which then
triggers 'check_if_startup_complete()' that will find no pending action and mark
startup as complete even if the device could have been activated with another connection.
https://bugzilla.redhat.com/show_bug.cgi?id=1759956
It seems to complicate things more than helping. Drop it. What we still have
is a wrapper around plain g_dbus_connection_signal_subscribe(). That one is
trivial and helpful. The previous wrapper seems to add more complexity.
nm_dbus_connection_signal_subscribe_object_manager() wraps the subscription. The problem
is that this requires to pass a destroy notify function for cleaning up. Such a destroy
notify function will result in an idle source when unsubscribing, which keeps the associated
GMainContext alive (until it gets iterated some more). That seems error prone and outright
unsuitable for NMClient.
While the helper may be useful, it cannot be used by NMClient. So, there is only one
user of this function and we don't expect a second one. It seems better to get rid of
this wrapper and implement it directly.
This property is currently most likely not used. Also, because libnm doesn't
expose it and the only known user of this API (gnome-network-displays) doesn't
use it.
In the future we may want to expand on the Groups API. E.g. exposing groups as
separate D-Bus objects, in which case a better property type would be "ao" and
not "as". For now, that is unclear nor requested.
Remove the property for now.
Add VRF support to the daemon. When the device we are activating is a
VRF or a VRF's slave, put routes in the table specified by the VRF
connection.
Also, introduce a VRF device type in libnm.
There is however a serious issue currently: when NetworkManager creates
virtual devices, it starts from an unrealized NMDevice, creates the
netdev device, realizes the device, and transitions through states
UNMANAGED and DISCONNECTED. Thereby, the state of NMDevice gets cleared
again. That means, if the profile has "connection.stable-id=${RANDOM}"
and "ethernet.cloned-mac-address=stable", then we will first set a
random MAC address when creating the device. Then, the NMDevice
transitions through UNMANAGED state, forgets the MAC address it
generated and creates a new MAC address in stage 1. This should be
fixed by better handling unrealized devices. It also affects all
software devices that set the MAC address upon creation of the
interfaces (as they all should).
IP tunnels honor ethernet.cloned-mac-address. That is a MAC address of 6 bytes (ETH_ALEN).
Note that for example for gre tunnels, kernel exposes an address 00:00:00:00. Hence, trying
to set ethernet.cloned-mac-address with an gre tunnel leads to an assertion failure.
Instead, report and log a regular error.
Don't build the same sources multiple times. The test code should
statically link against the tested code, just like the device plugin
that uses the code in production.
Oddly enough, valgrind was not complaining about this leak...
Fixes: 87b2d783b6 ('core: accept 'ssids':aay option in RequestScan() dictionary parameter')
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
