Otherwise the uninitializeded objects could be prematurely signalled if their
paths are seen twice in quick succession. This happens when you have ethernet
hardware and add an ethernet connection -- it's immediatelly added to
AvialableConnections and the property reload signals the object addition
before the NMRemoteSettings's GetSettings() finishes:
# nmcli c add type ethernet autoconnect no ifname '*'
(process:4610): libnm-CRITICAL **: nm_connection_get_id: assertion 's_con != NULL' failed
Connection '(null)' ((null)) successfully added.
#
https://bugzilla.gnome.org/show_bug.cgi?id=754794
- accept a numeric value (decimal or hex (0x prefix))
- display a numeric value of the property in addition to the strings
- add/accept spaces between string names
to behave similar to other flags' properties.
Aliases "disable" and "disabled" are accepted too.
nmcli> set 802-3-ethernet.wake-on-lan none
It was possible to remove flags by setting a string containing just white
spaces, but it was user unfriendly and non-intuitive.
https://bugzilla.redhat.com/show_bug.cgi?id=1260584
#0 0x00007fc52202dd3b in g_logv (breakpoint=1) at gmessages.c:315
#1 0x00007fc52202dd3b in g_logv (log_domain=0x7fc522351b84 "GLib-GObject", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7ffeb818bfc0) at gmessages.c:1041
#2 0x00007fc52202deaf in g_log (log_domain=<optimized out>, log_level=<optimized out>, format=<optimized out>) at gmessages.c:1079
#3 0x000055c658ee819f in free_property_filter_data (pfd=0x55c65a009000) at nm-manager.c:4418
#4 0x000055c658ee7e67 in do_set_property_check (user_data=0x55c65a009000) at nm-manager.c:4515
#5 0x00007fc522026a8a in g_main_context_dispatch (context=0x55c659e161c0) at gmain.c:3122
#6 0x00007fc522026a8a in g_main_context_dispatch (context=context@entry=0x55c659e161c0) at gmain.c:3737
#7 0x00007fc522026e20 in g_main_context_iterate (context=0x55c659e161c0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3808
#8 0x00007fc522027142 in g_main_loop_run (loop=0x55c659e16280) at gmain.c:4002
#9 0x000055c658e047ee in main (argc=1, argv=0x7ffeb818c508) at main.c:449
Fixes: 751c674643
If at the moment when spawning nm-iface-helper dhcp4/slaac
did not yet complete, we would not enable it.
That is wrong. If the connection indicates to use dhcp4/slaac,
it should be used by nm-iface-helper without considering the
current state on the device.
https://bugzilla.redhat.com/show_bug.cgi?id=1260243
A GObject interface, like a class, has two different C types
associated with it; the type of the "class" struct (eg, GObjectClass,
GFileIface), and the type of instances of that class/interface (eg,
GObject, GFile).
NetworkManager was doing this wrong though, and using the same C type
to point to both the interface's class struct and to instances of the
interface. This ends up not actually breaking anything, since for
interface types, the instance type is a non-dereferenceable dummy type
anyway. But it's wrong, since if, eg, NMDeviceFactory is a struct type
containing members "start", "device_added", etc, then you should not
be using an NMDeviceFactory* to point to an object that does not
contain those members.
Fix this by splitting NMDeviceFactory into NMDeviceFactoryInterface
and NMDeviceFactory; by splitting NMConnectionProvider into
NMConnectionProviderInterface and NMConnectionProvider; and by
splitting NMSettingsPlugin into NMSettingsPluginInterface and
NMSettingsPlugin; and then use the right types in the right places.
As a bonus, this also lets us now use G_DEFINE_INTERFACE.
Since there have not been separate system and user settings services
since 0.8, the "system" in NMSystemConfigInterface is kind of
meaningless. Rename it to NMSettingsPlugin, which describes what it
does better.
This is just:
git mv src/settings/nm-system-config-interface.h src/settings/nm-settings-plugin.h
git mv src/settings/nm-system-config-interface.c src/settings/nm-settings-plugin.c
perl -pi -e 's/SystemConfigInterface/SettingsPlugin/g;' \
-e 's/system_config_interface/settings_plugin/g;' \
-e 's/system-config-interface/settings-plugin/g;' \
-e 's/SYSTEM_CONFIG_INTERFACE/SETTINGS_PLUGIN/g;' \
-e 's/sc_plugin/settings_plugin/g;' \
-e 's/SC_PLUGIN/SETTINGS_PLUGIN/g;' \
-e 's/SC_IS_PLUGIN/SETTINGS_IS_PLUGIN/g;' \
-e 's/SC_TYPE_PLUGIN/SETTINGS_TYPE_PLUGIN/g;' \
-e 's/SCPlugin/SettingsPlugin/g;' \
-e 's/nm_system_config_factory/nm_settings_plugin_factory/g;' \
$(find src/settings -type f)
(followed by some whitespace fixups in nm-settings-plugin.c, and a
Makefile.am fix for the rename)
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.
