Most logging lines already had a prefix like "(%s): ". With this change,
the prefix gets added automatically by the logging macro.
Other logging lines didn't have a prefix. But since we no longer log the
file location, it's not nice to see messages without prefix/location.
priv->ctx->cancellable is passed to mm_sim_send_pin() to cancel the
operation.
We must cancel the operation when the context/response is no longer
relevant.
Especially, as we don't take a reference on @self during the asyncronous
request.
We would subscribe to config-changed signal during object-realize,
however only unsubscribe during dispose().
Avoid multiple subscributions, and unsubscribe also when unrealizing
the device.
Also, always subscribe to the signal, even without capability
NM_DEVICE_CAP_CARRIER_DETECT. In the next commit, we will re-read
capabilities later on, so just always subscribe.
Contrary to gboolean, bool is only one byte in size.
Due to alignment and ordering of the fields, this saves
merely 16 bytes per NMDevicePrivate struct (on x86_64),
still.
Also, bool is coerced by the compiler to be strictly FALSE or
TRUE -- contrary to gboolean, which can be any integer.
Thus, for bool type, "g_assert (NM_IN_SET (value, FALSE, TRUE));"
never fails. That is desirable as well.
While not a large win, it seems favorable to use bool type for
fields of a struct.
We call the asynchrnous function mm_sim_send_pin() without taking a
reference on @self. During send_pin_ready() we must first check whether
the request was cancelled because self might be a dangling pointer at
this point.
Also, avoid leaking @error if the ctx is no longer valid.
Fixes: aa0b379699
When the IP status is IP_DONE and a DHCP transaction succeeds the
'dhcp4' and 'dhcp6' pending actions must be removed. Without this, a
temporary link loss just after the activation would cause a DHCP
restart and those actions would remain set, blocking the startup.
https://bugzilla.redhat.com/show_bug.cgi?id=1330893
If the device is disconnected, we should also disconnect the modem; and
while we disconnect the device we should clean the connection context.
Otherwise the modem will surprise us by emitting PREPARED signal when
the device is no longer PREPARED:
NetworkManager[28469]: <info> [1462383185.8714] (ttyACM1): modem state changed, 'disconnecting' --> 'registered' (reason: user-requested)
NetworkManager[28469]: <info> [1462383185.8715] (ttyACM1): modem state changed, 'registered' --> 'connecting' (reason: user-requested)
NetworkManager[28469]: <info> [1462383185.8716] device (ttyACM1): state change: deactivating -> disconnected (reason 'connection-removed') [110 30 38]
NetworkManager[28469]: <info> [1462383185.8759] (ttyACM1): modem state changed, 'connecting' --> 'disconnecting' (reason: user-requested)
NetworkManager[28469]: <warn> [1462383185.8937] (ttyACM1): failed to connect modem: Dial operation has been cancelled
(NetworkManager:28469): NetworkManager-wwan-CRITICAL **: modem_prepare_result: assertion 'state == NM_DEVICE_STATE_PREPARE' failed
Program received signal SIGTRAP, Trace/breakpoint trap.
g_logv (log_domain=0x7fffea31bc47 "NetworkManager-wwan", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7fffffffcfc0) at gmessages.c:1086
1086 g_private_set (&g_log_depth, GUINT_TO_POINTER (depth));
(gdb) bt
#0 0x00007ffff4ebe643 in g_logv (log_domain=0x7fffea31bc47 "NetworkManager-wwan", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7fffffffcfc0) at gmessages.c:1086
#1 0x00007ffff4ebe7bf in g_log (log_domain=<optimized out>, log_level=<optimized out>, format=<optimized out>) at gmessages.c:1119
Python Exception <type 'exceptions.RuntimeError'> Cannot locate object file for block.:
#2 0x00007ffff2ce6dac in ffi_call_unix64#3 0x00007ffff2ce66d5 in ffi_call (cif=cif@entry=0x7fffffffd300, fn=<optimized out>, rvalue=0x7fffffffd230, avalue=avalue@entry=0x7fffffffd1d0) at ../src/x86/ffi64.c:522
#4 0x00007ffff51b55a5 in g_cclosure_marshal_generic_va (closure=0x555555b30cb0, return_value=0x0, instance=0x555555a8d360, args_list=<optimized out>, marshal_data=0x0, n_params=2, param_types=0x555555c2bb60) at gclosure.c:1600
#5 0x00007ffff51b4b37 in _g_closure_invoke_va (closure=closure@entry=0x555555b30cb0, return_value=return_value@entry=0x0, instance=instance@entry=0x555555a8d360, args=args@entry=0x7fffffffd5b8, n_params=2, param_types=0x555555c2bb60) at gclosure.c:864
#6 0x00007ffff51ce117 in g_signal_emit_valist (instance=instance@entry=0x555555a8d360, signal_id=signal_id@entry=168, detail=detail@entry=0, var_args=var_args@entry=0x7fffffffd5b8) at gsignal.c:3292
#7 0x00007ffff51cf2e8 in g_signal_emit_by_name (instance=instance@entry=0x555555a8d360, detailed_signal=detailed_signal@entry=0x7fffea074cdd "prepare-result") at gsignal.c:3479
#8 0x00007fffea011fd3 in connect_context_step (self=self@entry=0x555555a8d360 [NMModemBroadband]) at nm-modem-broadband.c:529
#9 0x00007fffea01264d in connect_ready (simple_iface=<optimized out>, res=<optimized out>, self=0x555555a8d360 [NMModemBroadband]) at nm-modem-broadband.c:378
#10 0x00007ffff546a297 in g_simple_async_result_complete (simple=0x7fffe00104e0 [GSimpleAsyncResult]) at gsimpleasyncresult.c:801
#11 0x00007fffe9d82fec in connect_context_complete_and_free (ctx=ctx@entry=0x555555c52f60) at mm-modem-simple.c:93
#12 0x00007fffe9d83155 in simple_connect_ready (self=0x7fffdc00b9f0 [MMModemSimple], res=0x7fffdc004410, ctx=0x555555c52f60) at mm-modem-simple.c:159
#13 0x00007ffff547af93 in g_task_return_now (task=0x7fffdc004410 [GTask]) at gtask.c:1106
#14 0x00007ffff547b62e in g_task_return (task=0x7fffdc004410 [GTask], type=<optimized out>) at gtask.c:1164
#15 0x00007ffff54d4239 in reply_cb (connection=<optimized out>, res=<optimized out>, user_data=0x7fffdc004410) at gdbusproxy.c:2570
#16 0x00007ffff547af93 in g_task_return_now (task=0x7fffdc004340 [GTask]) at gtask.c:1106
#17 0x00007ffff547b62e in g_task_return (task=0x7fffdc004340 [GTask], type=<optimized out>) at gtask.c:1164
#18 0x00007ffff54c8c9f in g_dbus_connection_call_done (source=<optimized out>, result=0x555555a60920, user_data=0x7fffdc004340) at gdbusconnection.c:5702
#19 0x00007ffff547af93 in g_task_return_now (task=0x555555a60920 [GTask]) at gtask.c:1106
#20 0x00007ffff547afc9 in complete_in_idle_cb (task=0x555555a60920) at gtask.c:1120
#21 0x00007ffff4eb7d7a in g_main_context_dispatch (context=0x555555a4a000) at gmain.c:3152
#22 0x00007ffff4eb7d7a in g_main_context_dispatch (context=context@entry=0x555555a4a000) at gmain.c:3767
#23 0x00007ffff4eb80b8 in g_main_context_iterate (context=0x555555a4a000, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3838
#24 0x00007ffff4eb838a in g_main_loop_run (loop=0x555555a48780) at gmain.c:4032
#25 0x00005555555aebf2 in main (argc=1, argv=0x7fffffffdc48) at main.c:477
(gdb)
If libmm invokes callbacks after the connect context has been disposed
we should just ignore them. Fixes crash on dereferencing already freed
connect context (due to explicit disconnection while the modem is
connecting):
NetworkManager[29074]: <info> [1462383917.8718] (ttyACM1): modem state changed, 'disconnecting' --> 'registered' (reason: user-requested)
NetworkManager[29074]: <info> [1462383917.8719] (ttyACM1): modem state changed, 'registered' --> 'connecting' (reason: user-requested)
NetworkManager[29074]: <info> [1462383917.8720] device (ttyACM1): state change: deactivating -> disconnected (reason 'connection-removed') [110 30 38]
NetworkManager[29074]: <info> [1462383917.8758] (ttyACM1): modem state changed, 'connecting' --> 'disconnecting' (reason: user-requested)
NetworkManager[29074]: <warn> [1462383917.8909] (ttyACM1): failed to connect modem: Dial operation has been cancelled
(NetworkManager:29074): NetworkManager-wwan-CRITICAL **: modem_prepare_result: assertion 'state == NM_DEVICE_STATE_PREPARE' failed
NetworkManager[29074]: <info> [1462383917.8912] (ttyACM1): modem state changed, 'disconnecting' --> 'registered' (reason: user-requested)
NetworkManager[29074]: <info> [1462383917.8913] (ttyACM1): modem state changed, 'registered' --> 'connecting' (reason: user-requested)
NetworkManager[29074]: <info> [1462383917.9693] (ttyACM1): modem state changed, 'connecting' --> 'registered' (reason: user-requested)
Program received signal SIGSEGV, Segmentation fault.
connect_ready (simple_iface=<optimized out>, res=0x7fffe0009200, self=0x555555a8d670 [NMModemBroadband]) at nm-modem-broadband.c:329
329 if (!ctx->first_error) {
(gdb) bt
#0 0x00007fffea01272a in connect_ready (simple_iface=<optimized out>, res=0x7fffe0009200, self=0x555555a8d670 [NMModemBroadband]) at nm-modem-broadband.c:329
#1 0x00007ffff546a297 in g_simple_async_result_complete (simple=0x7fffe0009200 [GSimpleAsyncResult]) at gsimpleasyncresult.c:801
#2 0x00007fffe9d82fec in connect_context_complete_and_free (ctx=ctx@entry=0x7fffdc00c550) at mm-modem-simple.c:93
#3 0x00007fffe9d83155 in simple_connect_ready (self=0x7fffdc00c960 [MMModemSimple], res=0x555555a7c2b0, ctx=0x7fffdc00c550) at mm-modem-simple.c:159
#4 0x00007ffff547af93 in g_task_return_now (task=0x555555a7c2b0 [GTask]) at gtask.c:1106
#5 0x00007ffff547b62e in g_task_return (task=0x555555a7c2b0 [GTask], type=<optimized out>) at gtask.c:1164
#6 0x00007ffff54d4239 in reply_cb (connection=<optimized out>, res=<optimized out>, user_data=0x555555a7c2b0) at gdbusproxy.c:2570
#7 0x00007ffff547af93 in g_task_return_now (task=0x7fffdc004470 [GTask]) at gtask.c:1106
#8 0x00007ffff547b62e in g_task_return (task=0x7fffdc004470 [GTask], type=<optimized out>) at gtask.c:1164
#9 0x00007ffff54c8c9f in g_dbus_connection_call_done (source=<optimized out>, result=0x7fffe00036f0, user_data=0x7fffdc004470) at gdbusconnection.c:5702
#10 0x00007ffff547af93 in g_task_return_now (task=0x7fffe00036f0 [GTask]) at gtask.c:1106
#11 0x00007ffff547afc9 in complete_in_idle_cb (task=0x7fffe00036f0) at gtask.c:1120
#12 0x00007ffff4eb7d7a in g_main_context_dispatch (context=0x555555a4a000) at gmain.c:3152
#13 0x00007ffff4eb7d7a in g_main_context_dispatch (context=context@entry=0x555555a4a000) at gmain.c:3767
#14 0x00007ffff4eb80b8 in g_main_context_iterate (context=0x555555a4a000, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3838
#15 0x00007ffff4eb838a in g_main_loop_run (loop=0x555555a48780) at gmain.c:4032
#16 0x00005555555aebf2 in main (argc=1, argv=0x7fffffffdc78) at main.c:477
(gdb)
Once we start with dispose, we certainly don't want to process any platform
events for the device anymore.
Previously, we disconnect those handlers only later during dispose, so it's
not clear that we would not receive a device_ipx_changed signal after _cleanup_generic_pre().
Fix this possible (or actual) bug.
Since commit a47c13a7a2, update_ip4_config() re-schedules
itself in case activate_stage5_ip4_config_commit is pending. Thus, there is no need to
cancel any queued queued_ip4_config_id.
Also as that does not properly fix the issue unlike a47c13a7a.
update_ip4_config() and update_ip6_config() are called from nm_device_capture_initial_config().
At that point, we don't expect any activation-source scheduled, thus the "if" should not
not be hit anyway.
So, this patch should actually make no difference, but it seems clearer
to me. Also, because it would be a bug to re-schedule the idle handler
that is already pending, but from inspecting nm_device_capture_initial_config()
it is not immediately clear that this cannot be the case.
Make DHCPv6 more robust WRT temporary failures of servers by retrying
DHCP for a predefined number of times at regular intervals when the
lease expires.
https://bugzilla.gnome.org/show_bug.cgi?id=741347
Make DHCPv4 more robust WRT temporary failures of servers by retrying
DHCP for a predefined number of times at regular intervals when the
lease expires.
https://bugzilla.gnome.org/show_bug.cgi?id=741347
Introduce the nm_device_ip_method_failed() function to check if the
failure of an IP method should cause the activation to fail, and use
it where appropriate.
http://bugzilla.gnome.org/show_bug.cgi?id=741347
When a new dynamic configuration is received, it is stored in a member
of private structure (e.g. @dhcp6_ip6_config) and a commit is
scheduled. Before the commit is executed, an update_ipx_config() could
be called and it would change the configuration before it is
committed.
This race condition causes failures in assigning the addresses
received through DHCPv6 when the internal client is used (but
potentially other clients and methods are affected).
To fix it, postpone updates of IP configurations when a commit is
already pending.
The "source" field of NMPlatformIPRoute (now "rt_source") maps to the
protocol field of the route. The source of NMPlatformIPAddress (now
"addr_source") has no direct equivalent in the kernel.
As their use is different, they should have different names. Also,
the name "source" is used all over the place. Hence give the fields
a more distinct name.
The 'portname' sysfs attribute of s390 devices is deprecated since
kernel 4.4 and always set to 'no portname required'. But even on older
kernels such value must be interpreted as an unset portname and thus
ignored.
https://bugzilla.redhat.com/show_bug.cgi?id=1327204
Already previously, the mode and rc-manager were intertwined in a complicated
way:
- dns=none effectively disables rc-manager.
- if resolv.conf was immutable, it would disable the rc-manager
by setting "resolv_conf_mode=NM_DNS_MANAGER_RESOLV_CONF_UNMANAGED".
- resolv_conf_mode was anyway a redundant piece of information to
rc_manager.
Now there are only two relevant settings: priv->plugin and
priv->rc_manager. And they can be set independently from each other.
Before that was not possible. For example, you could not set a
dns plugin with rc-manager=unmanaged (the only way to achive that
was via an immutable resolv.conf or by having rc-manager=symlink
and let resolv.conf link somewhere else.
Generate a stable connection UUID for the default-wired-connection.
Otherwise, on every reboot, the UUID changes although the generated
connection is the same.
But also hash into the UUID the machine-id, the device name and the
hardware address. So, the UUID is only the same if the connection is
identical in every aspect.
Also, the UUID is used as Network_ID for the stable-privacy address
generation mode. It is bad to re-create different UUIDs on every boot
as it causes different addresses.
The infiniband drivers don't implement the rtnetlink link deletions.
Therefore we unrealize the NMDevice instance but the backing resources
stay around, preventing us from ever realizing the device again.
The device creation can be attempted if the name can be determined. It
alone is doesn't mean that there's a parent device -- the name could
just have been hardcoded in the connection.
NetworkManager[21519]: nm_device_get_ifindex: assertion 'NM_IS_DEVICE (self)' failed
Program received signal SIGTRAP, Trace/breakpoint trap.
g_logv (log_domain=0x5555557fb2e5 "NetworkManager", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7fffffffd3d0) at gmessages.c:1046
1046 g_private_set (&g_log_depth, GUINT_TO_POINTER (depth));
(gdb) bt
#0 0x00007ffff4ec88c3 in g_logv (log_domain=0x5555557fb2e5 "NetworkManager", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7fffffffd3d0) at gmessages.c:1046
#1 0x00007ffff4ec8a3f in g_log (log_domain=<optimized out>, log_level=<optimized out>, format=<optimized out>) at gmessages.c:1079
#2 0x00005555555d2090 in nm_device_get_ifindex (self=0x0) at devices/nm-device.c:562
#3 0x00005555555ef77a in nm_device_supports_vlans (self=0x0) at devices/nm-device.c:9865
#4 0x00005555555bf2f9 in create_and_realize (device=0x555555c549b0 [NMDeviceVlan], connection=0x555555b451e0, parent=0x0, out_plink=0x7fffffffd5f8, error=0x7fffffffd700) at devices/nm-device-vlan.c:225
#5 0x00005555555d5757 in nm_device_create_and_realize (self=0x555555c549b0 [NMDeviceVlan], connection=0x555555b451e0, parent=0x0, error=0x7fffffffd700) at devices/nm-device.c:1783
#6 0x0000555555688601 in system_create_virtual_device (self=0x555555af51c0 [NMManager], connection=0x555555b451e0) at nm-manager.c:1120
#7 0x000055555568894e in connection_changed (settings=0x555555ae8220 [NMSettings], connection=0x555555b451e0, manager=0x555555af51c0 [NMManager]) at nm-manager.c:1172
#8 0x0000555555693448 in nm_manager_start (self=0x555555af51c0 [NMManager], error=0x7fffffffda30) at nm-manager.c:4466
#9 0x00005555555d166f in main (argc=1, argv=0x7fffffffdba8) at main.c:454
(gdb)
Fixes: 332994f1b1
update_connection() may be called during startup when the bus watch
hasn't notified yet the presence (or absence) of the teamd service on
the bus. Try to obtain a connection to the service in order to
retrieve the current configuration.
If the connection specifies an interface name, it should never attach to
a device of a different name even if the factory thinks the connection
is compatible with the device.
This fixes an issue that caused the inifniband connections to attach to
different devices or partitions.
When we want to preserve the default-route on cleanup, we must first
set it to assumed, before clearing it. Otherwise, NMDefaultRouteManager's
update() will delete the default route.
This is the oposite of the deconfigure case, where we first set it to
!has && !assumed, to force the route-manager to delete the route.
Add a function _update_default_route() to set the default_route
flags and call update() in one step.
Also, if there are no changes, skip the call to NMDefaultRouteManager's
update().
