Without that the device is not properly initialized. It misses hardware
address and type description.
Testcase:
$ sudo ip link add dummy0 type dummy
$ nmcli device
DEVICE TYPE STATE CONNECTION
em1 ethernet connected Ethernet connection 1
FF wifi connected --
bond0 bond unmanaged --
bond1 bond unmanaged --
dummy0 unmanaged --
lo unmanaged --
Fixes: e8139f56c2
There seems to be an issue with glib/ffi that causes failures
to pass enum-typed arguments to signals (related bug rh#1260577).
Add a test for platform signals which, beside NM_CONFIG_SIGNAL_CONFIG_CHANGED,
is the only place where we use enum-typed arguments for signals.
Strangely, this test doesn't cause the failure, so it's unclear why
the workaround was necessary for "config-changed" signal (commit
e7d66f1df6).
There seems to be a bug in glib/ffi that hits on s390x/ppc64 architecture.
It causes @changes in nm-dns-manager.c:config_changed_cb() to be NONE,
although it is clearly set (see the related bug rh #1260577 for glib).
Workaround this, by making the argument type a plain guint.
Note that the ill behavior is caught by test_config_signal() in
"src/tests/config/test-config.c".
Related: https://bugzilla.redhat.com/show_bug.cgi?id=1062301
If DHCP fails for an assumed connection, NetworkManager would
transition the device to the FAILED and then to the ACTIVATED state
(because it is assumed); hence if the DHCP server goes temporarily
down the device will go into a permanent state without IP
configuration.
Fix this and try DHCP again after some time when the connection
is an assumed one.
https://bugzilla.redhat.com/show_bug.cgi?id=1246496
This would cause the ip_vti0 generic device (that appears upon insertion of
ip_vti module during libreswan ipsec stack init) to go managed and brought UP.
Without addresses assigned the device would cause all the VPN traffic to
disappear in the oblivion.
Addresses the clash between the two commits which would cause the parent device
gateway to be overwritten with 0.0.0.0 upon route-based VPN activation:
Fixes: 063677101a
Fixes: 1465c1d326
Program received signal SIGSEGV, Segmentation fault.
0x0000555555646b59 in platform_link_added (self=self@entry=0x5555559fe1d0,
ifindex=<optimized out>, plink=plink@entry=0x555555b10a70)
at nm-manager.c:1889
1889 nm_log_warn (LOGD_HW, "%s: factory failed to create device: %s",
(gdb) bt
#0 0x0000555555646b59 in platform_link_added (self=self@entry=0x5555559fe1d0, ifindex=<optimized out>, plink=plink@entry=0x555555b10a70) at nm-manager.c:1889
#1 0x000055555564980c in nm_manager_start (self=0x5555559fe1d0)
at nm-manager.c:1988
#2 0x000055555564980c in nm_manager_start (self=0x5555559fe1d0, error=error@entry=0x7fffffffe658) at nm-manager.c:4212
#3 0x00005555555ae173 in main (argc=1, argv=0x7fffffffe7c8) at main.c:428
(gdb)
On slow virtual machine, these tests could fail because the
timeout was too low. As in a successful run the timeouts should
not be reached anyway, just extend them.
The naming of these logging macros is unexpected, as we use such
macros only here in platform.
For these messages we cannot use the default _LOGD() set of macros,
because there is no @platform instance around. So let's introduce an
alternative set of logging macros (_LOG2D(), etc) and use it.
We already have the macros _LOGD(), _LOGI(), etc. to provide context sensitive
logging (such as printing the object pointer as prefix).
In some implementations, we would like to have a second set of logging
macros, that shall be used differently. For example, use the default
_LOGD() for messages that are explicitly issued by one objects, and use
_LOG2D() in a static context when no object is around.
The "_LOG2" prefix is not great from a naming point of view. However, it is
meant to be a second (alternative) set of logging macros with the same
usage pattern as the _LOGD() macros.
When a new link is detected, NM tries to generate a default "Wired
connection" in nm_settings_device_added(), but if the link has not
been initialized by udev yet the function returns early because
priv->unmanaged_flags = UNMANAGED_PLATFORM_INIT.
To be sure that a default connection is created is such situation, we
need to call again nm_settings_device_added() after link
initialization.
https://bugzilla.redhat.com/show_bug.cgi?id=1254089
Those are not required with systemd-udevd v210 or newer. This way
distros which have a new enough version of udev can skip installing
84-nm-drivers.rules. While at it, don't use absolute paths for sed and
ethtool.
test-dispatcher-envp.c: In function 'test_generic':
test-dispatcher-envp.c:507:3: error: format not a string literal and no format arguments [-Werror=format-security]
Don't disconnect the device when the DHCP renewal fails and there are
already configured static IP addresses on the device. Instead, keep
the device up and try DHCP again after some time.
https://bugzilla.redhat.com/show_bug.cgi?id=1168388
check_if_startup_complete() could be invoked from nm_settings_start() before
devices had chance to be added, which results in premature "startup complete"
and NM would quit when configure-and-quit=yes is set up.
Postpone actual check_if_startup_complete() resolution until we add all devices
and they are processed.
(gdb) bt
#0 0x00005555556401f3 in check_if_startup_complete (self=0x5555559f91d0)
at nm-manager.c:719
#1 0x00007ffff4d69de8 in g_closure_invoke () at /lib64/libgobject-2.0.so.0
#2 0x00007ffff4d7b70d in signal_emit_unlocked_R ()
at /lib64/libgobject-2.0.so.0
#3 0x00007ffff4d83471 in g_signal_emit_valist () at /lib64/libgobject-2.0.so.0
#4 0x00007ffff4d8372f in g_signal_emit () at /lib64/libgobject-2.0.so.0
#5 0x00007ffff4d6e4b5 in g_object_dispatch_properties_changed ()
at /lib64/libgobject-2.0.so.0
#6 0x00007ffff4d709d9 in g_object_notify () at /lib64/libgobject-2.0.so.0
#7 0x00005555556e232c in check_startup_complete (self=self@entry=0x555555a0e130) at settings/nm-settings.c:204
#8 0x00005555556e5203 in nm_settings_start (self=0x555555a0e130, error=error@entry=0x7fffffffe658) at settings/nm-settings.c:2122
#9 0x0000555555646d06 in nm_manager_start (self=0x5555559f91d0, error=0x7fffffffe658) at nm-manager.c:4153
#10 0x00005555555add43 in main (argc=1, argv=0x7fffffffe7c8) at main.c:428
(gdb)
Fixes:Beaker:NetworkManager_Test37_run_once_new_connection
https://bugzilla.redhat.com/show_bug.cgi?id=1256772
