The interface is owned by the parent NMDeviceBt and is not independently
usable. If not ignored, NM tries to assume a connection on the bnep
interface and messes the Bluetooth connection up.
(cherry picked from commit 8c113e4fc8)
The addition of Bluez5 support mistakenly broke support for Bluez4 property
change events. Bluez4 uses a custom D-Bus interface that we must explicitly
handle.
This caused NM to ignore BT devices immediately after pairing, since the UUIDs
only show up through a custom Bluez4 PropertyChanged even when pairing is
complete. Only then do we finally know priv->capabilities, and only then is
the NMBluezDevice usable.
(cherry picked from commit a949c38d8e)
We only want to treat a veth device as ethernet if (a) NM is running
inside a container, and (b) the veth in question is the "inside" end
of the veth, not the outside. Unfortunately, we don't have good
heuristics for this at the moment, so just ignore veths for now.
https://bugzilla.gnome.org/show_bug.cgi?id=731014
(cherry picked from commit ebeaeaed4d)
An assertion in nm_dhcp4_config_get_dbus_path() has been actually fixed
by 3d6936b2cc (hopefully for all cases).
But still I think we should check _config here instead of _client.
(cherry picked from commit 4dcfdec347)
backtrace:
#0 0x0000003370c504e9 in g_logv (log_domain=0x4c14cc "NetworkManager", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7fff420d05c0) at gmessages.c:989
#1 0x0000003370c5063f in g_log (log_domain=log_domain@entry=0x4c14cc "NetworkManager", log_level=log_level@entry=G_LOG_LEVEL_CRITICAL, format=format@entry=0x3370cbc89a "%s: assertion '%s' failed") at gmessages.c:1025
#2 0x0000003370c50679 in g_return_if_fail_warning (log_domain=log_domain@entry=0x4c14cc "NetworkManager", pretty_function=pretty_function@entry=0x4b4710 <__PRETTY_FUNCTION__.35285> "nm_device_get_iface",
expression=expression@entry=0x4b160a "self != NULL") at gmessages.c:1034
#3 0x000000000042e39b in nm_device_get_iface (self=0x0) at devices/nm-device.c:501
#4 0x00000000004393cc in nm_device_activate_stage3_ip_config_start (user_data=<optimized out>) at devices/nm-device.c:4062
#5 0x0000003370c492a6 in g_main_dispatch (context=0x153b190) at gmain.c:3066
#6 g_main_context_dispatch (context=context@entry=0x153b190) at gmain.c:3642
#7 0x0000003370c49628 in g_main_context_iterate (context=0x153b190, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3713
#8 0x0000003370c49a3a in g_main_loop_run (loop=0x153ae30) at gmain.c:3907
#9 0x0000000000429f15 in main (argc=1, argv=0x7fff420d0b78) at main.c:678
Signed-off-by: Thomas Haller <thaller@redhat.com>
(cherry picked from commit f4db6f13cb)
Check if teamd is already running before trying to connect, else it would fail
anyway with errors:
libteamdctl: teamdctl_connect: Failed to connect using all CLIs.
NetworkManager[5535]: <error> [1402495644.226625] [devices/nm-device-team.c:208] ensure_teamd_connection(): (TTT): failed to connect to teamd (err=-22)
# ip link set name TTT type team
(cherry picked from commit a78386b6d1)
An activating device may have an IP config that is unrelated to
the current activation (for example if it comes from capturing
the existing config when NM is started), and that config might
not have a gateway, which would have NM ignore that the device
is activating until after DHCP.
https://bugzilla.gnome.org/show_bug.cgi?id=726400
[thaller@redhat.com: move variables inside if-block]
Signed-off-by: Thomas Haller <thaller@redhat.com>
(cherry picked from commit 86ca7dce0c)
When starting, the initally loaded addresses were not fixed to have
absolute lifetimes.
This also leads to a crash due to failed assertion[1], when having
already expired addresses during NetworkManager start.
[1] backtrace:
#0 0x00007f39db91ec39 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x00007f39db920348 in __GI_abort () at abort.c:89
#2 0x00007f39dc35a0ed in _g_log_abort () at gmessages.c:255
#3 0x00007f39dc377c97 in g_assertion_message (domain=domain@entry=0x7f39e0085c67 "NetworkManager", file=file@entry=0x7f39e007f070 "platform/nm-linux-platform.c", line=line@entry=1146,
func=func@entry=0x7f39e0081430 <__FUNCTION__.23775> "_init_ip_address_lifetime", message=message@entry=0x7f39e13828b0 "assertion failed: (a_preferred <= a_valid && a_valid > 0 && a_preferred > 0)") at gtestutils.c:2278
#4 0x00007f39dc377cfa in g_assertion_message_expr (domain=domain@entry=0x7f39e0085c67 "NetworkManager", file=file@entry=0x7f39e007f070 "platform/nm-linux-platform.c", line=line@entry=1146,
func=func@entry=0x7f39e0081430 <__FUNCTION__.23775> "_init_ip_address_lifetime", expr=expr@entry=0x7f39e007f4e8 "a_preferred <= a_valid && a_valid > 0 && a_preferred > 0") at gtestutils.c:2293
#5 0x00007f39e0004608 in _init_ip_address_lifetime (address=address@entry=0x7fff7f8a2580, rtnladdr=rtnladdr@entry=0x7f39e12cdb20) at platform/nm-linux-platform.c:1144
#6 0x00007f39e0004ae4 in init_ip6_address (address=address@entry=0x7fff7f8a2580, rtnladdr=rtnladdr@entry=0x7f39e12cdb20) at platform/nm-linux-platform.c:1216
#7 0x00007f39e000a75e in ip6_address_get_all (platform=<optimized out>, ifindex=3) at platform/nm-linux-platform.c:3342
#8 0x00007f39e0032729 in nm_ip6_config_capture (ifindex=ifindex@entry=3, capture_resolv_conf=capture_resolv_conf@entry=0, use_temporary=use_temporary@entry=NM_SETTING_IP6_CONFIG_PRIVACY_UNKNOWN) at nm-ip6-config.c:303
#9 0x00007f39dffee8fa in update_ip_config (self=0x7f39e1380300, initial=<optimized out>) at devices/nm-device.c:5841
#10 0x00007f39dffef52a in nm_device_capture_initial_config (dev=<optimized out>) at devices/nm-device.c:5869
#11 0x00007f39e003e74e in get_existing_connection (manager=manager@entry=0x7f39e132b150, device=device@entry=0x7f39e1380300) at nm-manager.c:1576
#12 0x00007f39e003edb2 in add_device (self=self@entry=0x7f39e132b150, device=device@entry=0x7f39e1380300, generate_con=<optimized out>) at nm-manager.c:1826
#13 0x00007f39e003f503 in platform_link_added (reason=<optimized out>, plink=0x7f39e1372340, ifindex=3, self=0x7f39e132b150) at nm-manager.c:2205
#14 platform_link_cb (platform=<optimized out>, ifindex=3, plink=0x7f39e1372340, change_type=<optimized out>, reason=<optimized out>, user_data=<optimized out>) at nm-manager.c:2220
#15 0x00007f39da868d8c in ffi_call_unix64 () at ../src/x86/unix64.S:76
#16 0x00007f39da8686bc in ffi_call (cif=cif@entry=0x7fff7f8a2a40, fn=0x7f39e003f360 <platform_link_cb>, rvalue=0x7fff7f8a29b0, avalue=avalue@entry=0x7fff7f8a2930) at ../src/x86/ffi64.c:522
#17 0x00007f39dc84aad8 in g_cclosure_marshal_generic (closure=0x7f39e1368080, return_gvalue=0x0, n_param_values=<optimized out>, param_values=<optimized out>, invocation_hint=<optimized out>, marshal_data=0x0) at gclosure.c:1454
#18 0x00007f39dc84a298 in g_closure_invoke (closure=0x7f39e1368080, return_value=return_value@entry=0x0, n_param_values=5, param_values=param_values@entry=0x7fff7f8a2c40, invocation_hint=invocation_hint@entry=0x7fff7f8a2be0)
at gclosure.c:777
#19 0x00007f39dc85c35d in signal_emit_unlocked_R (node=node@entry=0x7f39e12c16c0, detail=detail@entry=0, instance=instance@entry=0x7f39e12c30a0, emission_return=emission_return@entry=0x0,
instance_and_params=instance_and_params@entry=0x7fff7f8a2c40) at gsignal.c:3586
#20 0x00007f39dc8640f2 in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7fff7f8a2e20) at gsignal.c:3330
#21 0x00007f39dc8643af in g_signal_emit (instance=<optimized out>, signal_id=<optimized out>, detail=detail@entry=0) at gsignal.c:3386
#22 0x00007f39e000e24c in nm_platform_query_devices () at platform/nm-platform.c:330
#23 0x00007f39e0040f30 in nm_manager_start (self=0x7f39e132b150) at nm-manager.c:4207
#24 0x00007f39dffe53ab in main (argc=1, argv=0x7fff7f8a3468) at main.c:657
Regression introduced by commit 8310a039d8.
https://bugzilla.gnome.org/show_bug.cgi?id=732472
Signed-off-by: Thomas Haller <thaller@redhat.com>
(cherry picked from commit 2a89258562)
impl_settings_get_connection_by_uuid() was changed from a synchronous
function to an asynchronous one. Thereby the @out_object_path argument
was forgotten, leaving the function completely broken.
This bug has the potential to crash NetworkManager.
Regression introduced by commit 8ab8990938.
Found running
$ ./dfuzzer -v -n com.redhat.ifcfgrh1
Related: https://bugzilla.redhat.com/show_bug.cgi?id=1113508
Signed-off-by: Thomas Haller <thaller@redhat.com>
(cherry picked from commit c35d63ddea)
When the slave device gets removed, the master is not in a state-change when
calling nm_device_release_one_slave(). This triggers a warning [1].
[1] backtrace:
#0 0x0000003370c504e9 in g_logv (log_domain=0x4c144c "NetworkManager", log_level=G_LOG_LEVEL_WARNING, format=<optimized out>, args=args@entry=0x7fff8b1d35b0) at gmessages.c:989
#1 0x0000003370c5063f in g_log (log_domain=log_domain@entry=0x4c144c "NetworkManager", log_level=log_level@entry=G_LOG_LEVEL_WARNING, format=format@entry=0x3370cc1fdc "%s") at gmessages.c:1025
#2 0x0000003370c50956 in g_warn_message (domain=domain@entry=0x4c144c "NetworkManager", file=file@entry=0x4b14d5 "devices/nm-device.c", line=line@entry=841, func=func@entry=0x4b48f0 <__FUNCTION__.35456> "nm_device_release_one_slave",
warnexpr=warnexpr@entry=0x0) at gmessages.c:1058
#3 0x0000000000436c30 in nm_device_release_one_slave (dev=dev@entry=0xd92540, slave=slave@entry=0xdb0e50, configure=configure@entry=1) at devices/nm-device.c:841
#4 0x000000000043a779 in slave_state_changed (slave=0xdb0e50, slave_new_state=NM_DEVICE_STATE_UNMANAGED, slave_old_state=NM_DEVICE_STATE_ACTIVATED, reason=<optimized out>, self=0xd92540) at devices/nm-device.c:1214
#5 0x0000003371805d8c in ffi_call_unix64 () at ../src/x86/unix64.S:76
#6 0x00000033718056bc in ffi_call (cif=cif@entry=0x7fff8b1d3a00, fn=0x43a677 <slave_state_changed>, rvalue=0x7fff8b1d3970, avalue=avalue@entry=0x7fff8b1d38f0) at ../src/x86/ffi64.c:522
#7 0x0000003371c10ad8 in g_cclosure_marshal_generic (closure=0xd76120, return_gvalue=0x0, n_param_values=<optimized out>, param_values=<optimized out>, invocation_hint=<optimized out>, marshal_data=0x0) at gclosure.c:1454
#8 0x0000003371c10298 in g_closure_invoke (closure=0xd76120, return_value=return_value@entry=0x0, n_param_values=4, param_values=param_values@entry=0x7fff8b1d3c00, invocation_hint=invocation_hint@entry=0x7fff8b1d3ba0) at gclosure.c:777
#9 0x0000003371c2235d in signal_emit_unlocked_R (node=node@entry=0xd9d850, detail=detail@entry=0, instance=instance@entry=0xdb0e50, emission_return=emission_return@entry=0x0,
instance_and_params=instance_and_params@entry=0x7fff8b1d3c00) at gsignal.c:3586
#10 0x0000003371c2a0f2 in g_signal_emit_valist (instance=instance@entry=0xdb0e50, signal_id=signal_id@entry=68, detail=detail@entry=0, var_args=var_args@entry=0x7fff8b1d3e38) at gsignal.c:3330
#11 0x0000003371c2a8f8 in g_signal_emit_by_name (instance=instance@entry=0xdb0e50, detailed_signal=detailed_signal@entry=0x4c3ce2 "state-changed") at gsignal.c:3426
#12 0x000000000043754f in _set_state_full (device=device@entry=0xdb0e50, state=state@entry=NM_DEVICE_STATE_UNMANAGED, reason=reason@entry=NM_DEVICE_STATE_REASON_REMOVED, quitting=quitting@entry=0) at devices/nm-device.c:6689
#13 0x000000000043797c in nm_device_state_changed (device=device@entry=0xdb0e50, state=state@entry=NM_DEVICE_STATE_UNMANAGED, reason=reason@entry=NM_DEVICE_STATE_REASON_REMOVED) at devices/nm-device.c:6823
#14 0x0000000000439fe7 in nm_device_set_unmanaged (device=device@entry=0xdb0e50, flag=flag@entry=NM_UNMANAGED_INTERNAL, unmanaged=unmanaged@entry=1, reason=reason@entry=NM_DEVICE_STATE_REASON_REMOVED) at devices/nm-device.c:5983
#15 0x00000000004799c2 in remove_device (manager=manager@entry=0xd86150, device=0xdb0e50, quitting=quitting@entry=0) at nm-manager.c:769
#16 0x000000000047e3bf in platform_link_cb (platform=<optimized out>, ifindex=35, plink=<optimized out>, change_type=<optimized out>, reason=<optimized out>, user_data=<optimized out>) at nm-manager.c:2123
#17 0x0000003371805d8c in ffi_call_unix64 () at ../src/x86/unix64.S:76
#18 0x00000033718056bc in ffi_call (cif=cif@entry=0x7fff8b1d4320, fn=0x47e34b <platform_link_cb>, rvalue=0x7fff8b1d4290, avalue=avalue@entry=0x7fff8b1d4210) at ../src/x86/ffi64.c:522
#19 0x0000003371c10ad8 in g_cclosure_marshal_generic (closure=0xd32e40, return_gvalue=0x0, n_param_values=<optimized out>, param_values=<optimized out>, invocation_hint=<optimized out>, marshal_data=0x0) at gclosure.c:1454
#20 0x0000003371c10298 in g_closure_invoke (closure=0xd32e40, return_value=return_value@entry=0x0, n_param_values=5, param_values=param_values@entry=0x7fff8b1d4520, invocation_hint=invocation_hint@entry=0x7fff8b1d44c0) at gclosure.c:777
#21 0x0000003371c2235d in signal_emit_unlocked_R (node=node@entry=0xcf5780, detail=detail@entry=0, instance=instance@entry=0xcf78a0, emission_return=emission_return@entry=0x0,
instance_and_params=instance_and_params@entry=0x7fff8b1d4520) at gsignal.c:3586
#22 0x0000003371c2a0f2 in g_signal_emit_valist (instance=instance@entry=0xcf78a0, signal_id=signal_id@entry=2, detail=detail@entry=0, var_args=var_args@entry=0x7fff8b1d4778) at gsignal.c:3330
#23 0x0000003371c2a8f8 in g_signal_emit_by_name (instance=instance@entry=0xcf78a0, detailed_signal=detailed_signal@entry=0x4b183d "link-changed") at gsignal.c:3426
#24 0x000000000044c6f3 in announce_object (platform=platform@entry=0xcf78a0, object=0xde1720, change_type=change_type@entry=NM_PLATFORM_SIGNAL_REMOVED, reason=reason@entry=NM_PLATFORM_REASON_EXTERNAL)
at platform/nm-linux-platform.c:1572
#25 0x000000000044ec07 in event_notification (msg=<optimized out>, user_data=<optimized out>) at platform/nm-linux-platform.c:1886
#26 0x0000003844c1117f in nl_cb_call (msg=<optimized out>, type=<optimized out>, cb=<optimized out>) at ../include/netlink-private/netlink.h:141
#27 recvmsgs (cb=0xcf7240, sk=0xcf7330) at nl.c:952
#28 nl_recvmsgs_report (sk=0xcf7330, cb=0xcf7240) at nl.c:1003
#29 0x0000003844c11549 in nl_recvmsgs (sk=<optimized out>, cb=<optimized out>) at nl.c:1027
#30 0x0000003844c11569 in nl_recvmsgs_default (sk=<optimized out>) at nl.c:1041
#31 0x000000000044e955 in event_handler (channel=<optimized out>, io_condition=<optimized out>, user_data=0xcf78a0) at platform/nm-linux-platform.c:3804
#32 0x0000003370c492a6 in g_main_dispatch (context=0xcf5190) at gmain.c:3066
#33 g_main_context_dispatch (context=context@entry=0xcf5190) at gmain.c:3642
#34 0x0000003370c49628 in g_main_context_iterate (context=0xcf5190, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3713
#35 0x0000003370c49a3a in g_main_loop_run (loop=0xcf4e30) at gmain.c:3907
#36 0x0000000000429f15 in main (argc=1, argv=0x7fff8b1d4f38) at main.c:678
Signed-off-by: Thomas Haller <thaller@redhat.com>
(cherry picked from commit 1dd50924c8)
dhcp4_cleanup() should first clear @dhcp4_client variables before
clearing @dhcp4_config. Otherwise the following assert fails [1] and
the DBUS property NM_DEVICE_DHCP4_CONFIG is set to %NULL.
Analog to dhcp6_cleanup(), dhcp6_client, and NM_DEVICE_DHCP6_CONFIG.
[1] backtrace:
#0 0x0000003370c504e9 in g_logv (log_domain=0x4c148c "unrecognized-specs-changed", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7fff4710ed60) at gmessages.c:989
#1 0x0000003370c5063f in g_log (log_domain=log_domain@entry=0x4c144c "NetworkManager", log_level=log_level@entry=G_LOG_LEVEL_CRITICAL, format=format@entry=0x3370cbc89a "%s: assertion '%s' failed") at gmessages.c:1025
#2 0x0000003370c50679 in g_return_if_fail_warning (log_domain=log_domain@entry=0x4c144c "NetworkManager", pretty_function=pretty_function@entry=0x4c6140 <__PRETTY_FUNCTION__.15969> "nm_dhcp4_config_get_dbus_path",
expression=expression@entry=0x4c60d9 "NM_IS_DHCP4_CONFIG (self)") at gmessages.c:1034
#3 0x000000000046b1d4 in nm_dhcp4_config_get_dbus_path (self=0x0) at nm-dhcp4-config.c:115
#4 0x0000000000434791 in get_property (object=0x9d2320, prop_id=13, value=0x9618a0, pspec=0x9bbc20) at devices/nm-device.c:7539
#5 0x0000003371c18e73 in object_get_property (value=0x9618a0, pspec=<optimized out>, object=0x9d2320) at gobject.c:1303
#6 g_object_get_property (object=0x9d2320, property_name=<optimized out>, value=0x9618a0) at gobject.c:2402
#7 0x000000000048482c in idle_id_reset (data=<optimized out>) at nm-properties-changed-signal.c:123
#8 0x0000003371c13055 in g_cclosure_marshal_VOID__PARAM (closure=0x9618a0, return_value=0xffffffff, n_param_values=0, param_values=0x7fff4710f130, invocation_hint=0x0, marshal_data=0x4b5201) at gmarshal.c:1037
#9 0x0000003371c10298 in g_closure_invoke (closure=0x2, closure@entry=0x919d00, return_value=return_value@entry=0x0, n_param_values=1192292656, param_values=0x9d2320, param_values@entry=0x7fff4710f130,
invocation_hint=invocation_hint@entry=0x7fff4710f0d0) at gclosure.c:777
#10 0x0000003371c21b87 in signal_emit_unlocked_R (node=node@entry=0x919d90, detail=detail@entry=667, instance=instance@entry=0x9d2320, emission_return=emission_return@entry=0x0,
instance_and_params=instance_and_params@entry=0x7fff4710f130) at gsignal.c:3516
#11 0x0000003371c2a0f2 in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7fff4710f2c0) at gsignal.c:3330
#12 0x0000003371c2a3af in g_signal_emit (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>) at gsignal.c:3386
#13 0x0000003371c14945 in g_object_dispatch_properties_changed (object=0x9d2320, n_pspecs=4294967295, pspecs=0x0) at gobject.c:1047
#14 0x0000003371c17019 in g_object_notify_by_spec_internal (pspec=<optimized out>, object=0x9d2320) at gobject.c:1141
#15 g_object_notify (object=0x9d2320, property_name=property_name@entry=0x4c400f "dhcp4-config") at gobject.c:1183
#16 0x0000000000434332 in dhcp4_cleanup (self=self@entry=0x9d2320, stop=stop@entry=1, release=release@entry=0) at devices/nm-device.c:2581
#17 0x0000000000434cab in _cleanup_generic_pre (self=self@entry=0x9d2320, deconfigure=deconfigure@entry=1) at devices/nm-device.c:6448
#18 0x0000000000436db1 in nm_device_cleanup (self=self@entry=0x9d2320, reason=reason@entry=NM_DEVICE_STATE_REASON_REMOVED) at devices/nm-device.c:6524
#19 0x0000000000437358 in _set_state_full (device=device@entry=0x9d2320, state=state@entry=NM_DEVICE_STATE_UNMANAGED, reason=reason@entry=NM_DEVICE_STATE_REASON_REMOVED, quitting=quitting@entry=0) at devices/nm-device.c:6641
#20 0x000000000043797c in nm_device_state_changed (device=device@entry=0x9d2320, state=state@entry=NM_DEVICE_STATE_UNMANAGED, reason=reason@entry=NM_DEVICE_STATE_REASON_REMOVED) at devices/nm-device.c:6823
#21 0x0000000000439fe7 in nm_device_set_unmanaged (device=device@entry=0x9d2320, flag=flag@entry=NM_UNMANAGED_INTERNAL, unmanaged=unmanaged@entry=1, reason=reason@entry=NM_DEVICE_STATE_REASON_REMOVED) at devices/nm-device.c:5983
#22 0x000000000043a193 in nm_device_set_unmanaged_quitting (device=0x9d2320) at devices/nm-device.c:5998
#23 0x00000000004799f9 in remove_device (manager=0x9b2150, device=0x9d2320, quitting=1) at nm-manager.c:775
#24 0x000000000047bf47 in dispose (object=0x9b2150) at nm-manager.c:4935
#25 0x0000003371c14ee8 in g_object_unref (_object=0x9b2150) at gobject.c:3160
#26 0x0000000000429f43 in main (argc=1, argv=0x7fff4710f9a8) at main.c:681
Signed-off-by: Thomas Haller <thaller@redhat.com>
(cherry picked from commit 3d6936b2cc)
When 'nm-dispatcher' is not running because its systemd service
'NetworkManager-dispatcher.service' is not enabled, any calls to the dispatcher
will fail with an error of typ DBUS_ERROR:DBUS_GERROR_REMOTE_EXCEPTION (32):
"Unit dbus-org.freedesktop.nm-dispatcher.service failed to load: No such file or directory."
This clutters the logfile with warnings, although the user probably
disabled the service on purpose.
Special case this particular (recurring) failure and downgrade the warning
to debug level.
Signed-off-by: Thomas Haller <thaller@redhat.com>
(cherry picked from commit 0d45284aa7)
If the timestamp is set to zero, the to_string() functions treat the lifetime
as based on *now*. For nm_platform_ip_address_cmp_expiry() this makes no
sense, because there is no absolute exiry to compare. Instead compare
them as expire earlier then the other address.
Signed-off-by: Thomas Haller <thaller@redhat.com>
The "lifetime" part when printing an address in nm_platform_ip[46]_address_to_string()
is supposed to show the raw, internal values of the address.
We already have the "lft" and "pref" output that presents the expiries based on now.
These fields are already crafted to show what the user probably wants
to see when looking at debugging log. "lifetime" should not do any
special casing and just print the raw values.
Signed-off-by: Thomas Haller <thaller@redhat.com>
When printing an address in nm_platform_ip4_address_to_string()
and nm_platform_ip6_address_to_string() treat an unset @timestamp
as counting from @now.
This is useful, if you just have the remaining lifetime at hand
and want to print an address. In general it is not a good idea to
leave the timestamp not anchored to an absolute @timestamp.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Previous patch 8310a039d8 modified
platform to set the timestamp of addresses always to 1.
So, when adding an address platform logging looked like:
signal: address 4 added: 192.168.232.3/24 lft 2000sec pref 1000sec lifetime 12345-1[13344,14344] dev em1 src kernel
This is confusing in the log file and during debugging. Instead set the
timestamp to the last modification time of the address so that it will
look like:
signal: address 4 added: 192.168.232.3/24 lft 2000sec pref 1000sec lifetime 12345-12345[1000,2000] dev em1 src kernel
Signed-off-by: Thomas Haller <thaller@redhat.com>
When setting the timestamp to 1, we have to subtract(!) one second
from a_valid and a_preferred.
Due to this error, NM saw the lifetimes of addresses from system as two
seconds larger then the actual value.
Signed-off-by: Thomas Haller <thaller@redhat.com>
nm_dhcp_dhclient_read_lease_ip_configs() calculates the remaining time
until the address expires. It must anchor the lifetimes by setting the
@timestamp to nm_utils_get_monotonic_timestamp_s().
Signed-off-by: Thomas Haller <thaller@redhat.com>
Previously, we would not check the content of the script directory.
This meant, that "/etc/NetworkManager/dispatcher.d" almost always
contained something, namely the "pre-up.d" and "pre-down.d" directories.
Improve that by searching the directories for at least one
executable file.
Also, debug log the detected state of the dispatcher directories.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Only truncate the script name to "basename" if the directory is the expected
one. Otherwise we print the raw value as returned by the dispatcher service.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Before, there was only one combined variable checking whether any dispatcher scripts
are present at all. This meant for example, that a call to PRE_UP was still sent out
even if no scripts were in pre-up.d/ directory.
Optimize this, by distinguishing between the dispatcher type and the script directories.
Signed-off-by: Thomas Haller <thaller@redhat.com>
- ensure, that dispatcher_results_process() logs a line even if no scripts
were run. This way we alyways know when the callout returns.
- log a line when cancelling a dispatcher call
Signed-off-by: Thomas Haller <thaller@redhat.com>
When delaying the deactivation of a device during dispatcher-pre-down,
we must preseve the reason to pass it on.
This is especially important, because nm_device_slave_notify_release()
checks for the reason, and does not deactivate the slave if no reason is
given. This error caused slaves the be left up when deactivating the master.
Also update the call to nm_device_slave_notify_release() to ensure we
have a valid state reason when configuring the slave. This would have
pointed out the issue and would even work around it.
Regression introduced by commit d00e2147de.
Signed-off-by: Thomas Haller <thaller@redhat.com>
NM fails to activate a slave if the master device already exists
but has not active connection.
One way to reproduce, create a bond master/slave configuration and
ensure that the master device exists (e.g. by activating the bond, and
killing NM without taking down the device, or externally via `ip link add`).
If you try to activate the slave it will fail with the following message
(in nmcli):
"Error: Connection activation failed: The active connection on MASTER is not a valid master for 'SLAVE'"
although MASTER is not active.
This also triggers the following assertion:
#0 0x0000003370c504e9 in g_logv () from /lib64/libglib-2.0.so.0
#1 0x0000003370c5063f in g_log () from /lib64/libglib-2.0.so.0
#2 0x000000000047646a in is_compatible_with_slave (master=0x0, slave=slave@entry=0xc4aa60) at nm-manager.c:2193
#3 0x000000000047e289 in ensure_master_active_connection (self=self@entry=0xc8d150, subject=0x7f23b80059e0, connection=connection@entry=0xc4aa60, device=device@entry=0xcac380, master_connection=master_connection@entry=0x0,
master_device=master_device@entry=0xc9e800, error=error@entry=0x7fffa5cc4958) at nm-manager.c:2395
#4 0x000000000047eb4a in _internal_activate_device (self=self@entry=0xc8d150, active=active@entry=0xcc33b0, error=error@entry=0x7fffa5cc4958) at nm-manager.c:2665
#5 0x000000000047ecf2 in _internal_activate_generic (self=self@entry=0xc8d150, active=active@entry=0xcc33b0, error=error@entry=0x7fffa5cc4958) at nm-manager.c:2712
#6 0x000000000047ef2b in _internal_activation_auth_done (active=0xcc33b0, success=<optimized out>, error_desc=0x0, user_data1=0xc8d150, user_data2=<optimized out>) at nm-manager.c:2848
#7 0x0000000000466fa1 in auth_done (chain=0xcef020, error=0x0, unused=<optimized out>, user_data=<optimized out>) at nm-active-connection.c:603
#8 0x00000000004753da in auth_chain_finish (user_data=0xcef020) at nm-manager-auth.c:88
#9 0x0000003370c492a6 in g_main_context_dispatch () from /lib64/libglib-2.0.so.0
#10 0x0000003370c49628 in g_main_context_iterate.isra () from /lib64/libglib-2.0.so.0
#11 0x0000003370c49a3a in g_main_loop_run () from /lib64/libglib-2.0.so.0
#12 0x0000000000429e65 in main (argc=1, argv=0x7fffa5cc4e48) at main.c:678
Signed-off-by: Thomas Haller <thaller@redhat.com>
Coverity gets confused and thinks we are potentially leaking bssid_str
here. Given that nm_utils_hwaddr_ntoa() never returns NULL anyway,
just drop the check.
(cherry picked from commit f4f4ecf159)
The G_DISABLE_CHECKS version of g_return_if_reached() still returns,
it just doesn't log. So don't include a manual return after a
return-if-reached.
(cherry picked from commit 3c13d9e3fd)
If a valid connection was updated and still valid, and then was
updated and become invalid, the connection would not be properly
removed from the ifnet plugin's priv->connections hash, and thus
would never be disposed.
This was due to using the direct pointer to the connection's UUID
as the key for the hash table. When a connection is updated and
its settings are replaced, the old UUID is freed and replaced with
a new pointer. But the ifnet plugin hash table still uses the
old (now freed) UUID pointer as the key. Thus when the connection
is updated and becomes invalid, looking up the UUID in the hash
table fails to find the connection, and the connection is not
removed from the hash.
This bug could cause a crash in some cases, if two keys of the
GHashTable hashed to the same value, in which case GLib would
call g_str_equal() on the freed pointer.
Since code other than in the ifnet plugin replaces settings,
we cannot be guaranteed that the pointer won't change. Avoid all
that and just strdup() the UUID when using it as a key.
Since the pointer to the connection's path could change any time
commit_changes() is called, it's not safe to use it as the hash
table key directly. strdup it instead.
Prevents:
Connection failed to verify: (unknown)
invalid or missing connection property 'blah blah/foo bar'
Simply removing the warning in reader.c is fine, because callers that
care already log the warning themselves. Also make the warning in
update_connection() the same as the warning in new_connection().
If a valid connection was updated and still valid, and then was
updated and become invalid, the connection would not be properly
removed from the keyfile plugin's priv->connections hash, and thus
would never be disposed.
This was due to using the direct pointer to the connection's UUID
as the key for the hash table. When a connection is updated and
its settings are replaced, the old UUID is freed and replaced with
a new pointer. But the keyfile plugin hash table still uses the
old (now freed) UUID pointer as the key. Thus when the connection
is updated and becomes invalid, looking up the UUID in the hash
table fails to find the connection, and the connection is not
removed from the hash.
This bug could cause a crash in some cases, if two keys of the
GHashTable hashed to the same value, in which case GLib would
call g_str_equal() on the freed pointer.
Since code other than in the keyfile plugin replaces settings,
we cannot be guaranteed that the pointer won't change. Avoid all
that and just strdup() the UUID when using it as a key.
(also collapses _internal_new_connection() into its only caller)
