Abstract class, fake implementation and a manual testing tool for
NetworkManager's internal IPv6 router discovery module. When a real
implementation is ready, it will replace nm-ip6-manager and will be used
by nm-device.
Callers of these functions now only care whether two IP configs are
different and not what specific property changed, so we can simplify
this code down to a simple comparison for equality, based on the hashing
that's already done for the DNS manager.
Note that this patch doesn't effectively change any code.
Functions moved from nm-system:
* nm_system_apply_ip?_config → nm_ip?_config_commit
* ip?_dest_in_same_subnet → nm_ip?_config_destination_is_direct
Functions moved from NetworkManagerUtils:
* nm_utils_merge_ip?_config → nm_ip?_config_merge_setting
Functions renamed (and moved down to form one group):
* nm_ip?_config_new_for_interface → nm_ip?_config_capture
(The rationale for the rename is that from the achitectural point of
view it doesn't matter whether the function creates a new object or
updates an existing one. After the rename, it's obvious that
nm_ip?_config_capture() and nm_ip?_config_commit() are counterparts of
each other.)
0652d9c596 changed IP states like this:
| old behaviour | new behaviour
---------------------------------------------------------
success | IP_DONE && config is not NULL | IP_DONE
failure | IP_DONE && config is NULL | IP_FAIL
But some failure paths was not updated.
nm_platform_*_sync() functions check the cached kernel configuration
items (addresses, routes) before adding addresses to the kernel.
Therefore we don't need to be so careful about pushing NetworkManager
configuration to the kernel.
This patch helps to avoid having to compare nm_ip[46]_config objects,
which should only be created when a configuration change is being
performed.
in nm_device_start_ip_check(), because it is called from the state handler
(nm_device_state_changed()).
Errors:
(devices/nm-device.c:5585):nm_device_state_changed: runtime check failed: (priv->in_state_changed == FALSE)
<info> (eth0): device state change: ip-check -> secondaries (reason 'none') [80 90 0]
dbus_connection_changed_cb() is called by DBUS_CONNECTION_CHANGED signal
that emits DBusConnection, not DBusGConnection.
The code was introduced by bd636ffb4068a75b204d99e798b5714f1bd5f24b; see it
for more information.
Reproducer: restart D-Bus daemon
(gdb) bt
#0 0xb7d40837 in pthread_mutex_lock () from /lib/libpthread.so.0
#1 0xb7cf946c in _dbus_platform_rmutex_lock () from /lib/libdbus-1.so.3
#2 0xb7ceba78 in _dbus_rmutex_lock () from /lib/libdbus-1.so.3
#3 0xb7cd5f2e in dbus_connection_add_filter () from /lib/libdbus-1.so.3
#4 0x080c40b5 in dbus_connection_changed_cb (dbus_mgr=0x8161b28, connection=0x81badc0, user_data=0x8189010)
at nm-manager.c:4499
#5 0xb7a6bfaa in g_cclosure_marshal_VOID__POINTER () from /lib/libgobject-2.0.so.0
#6 0xb7a69007 in g_closure_invoke () from /lib/libgobject-2.0.so.0
#7 0xb7a7afad in signal_emit_unlocked_R () from /lib/libgobject-2.0.so.0
#8 0xb7a83261 in g_signal_emit_valist () from /lib/libgobject-2.0.so.0
#9 0xb7a833e4 in g_signal_emit () from /lib/libgobject-2.0.so.0
#10 0x080b4136 in nm_dbus_manager_reconnect (user_data=0x8161b28) at nm-dbus-manager.c:568
#11 0xb7969e50 in g_timeout_dispatch () from /lib/libglib-2.0.so.0
#12 0xb796915b in g_main_context_dispatch () from /lib/libglib-2.0.so.0
#13 0xb7969500 in g_main_context_iterate.isra.22 () from /lib/libglib-2.0.so.0
#14 0xb7969963 in g_main_loop_run () from /lib/libglib-2.0.so.0
#15 0x08065e67 in main (argc=1, argv=0xbffff814) at main.c:629
NM handles the default routes, so they shouldn't show up in the NMIP6Config
for any interface. They get exposed via the 'default' and 'default6' properties
of the ActiveConnection instead.
The same has been done for IPv4 by c77c566983.
The 'assume' parameter was misused for stuff that has nothing to do with
connection assumption. The 'commit' argument with reversed logic is much
clearer.
This (together with a patch adding src/platform/Makefile.am) allows for
a workflow where your working directory is src/platform and all tests
and testing tools are rebuilt with your src/platform modifications.
The route metric is one of the object's key attributes and therefore
cannot be left to be chosen by the kernel. Instead, it must always be
specified explicitly. This matches the architecture of libnl3 and the
current API provided by nm-platform.
Previously I didn't think they'd be used for anything other than connection secrets
which only have one hint, but in the future we'll want to pass more information.
Split the agent secrets request tracking structure into a generic
structure for tracking any agent request, and a connection-specific
subclass. We'll use the generic structure in the future for device
secrets and other stuff.
Bonding options are written straight into [bond] group like:
[bond]
interface-name=bbb
mode-active-backup
miimon=300
So we have to handle them explicitly.
