(gdb) bt
#0 0x00007ffff4d9e075 in g_type_check_instance_is_fundamentally_a (type_instance=type_instance@entry=0x-1, fundamental_type=fundamental_type@entry=80) at gtype.c:4030
#1 0x00007ffff4d7e447 in g_object_unref (_object=0xffffffffffffffff) at gobject.c:3076
#2 0x00007fffe89cdfa8 in disconnect_context_complete (ctx=ctx@entry=0x555555b4c680) at nm-modem-broadband.c:1062
#3 0x00007fffe89cf6e5 in disconnect (modem=<optimized out>, warn=0, cancellable=0x0, callback=0x0, user_data=0x0) at nm-modem-broadband.c:1126
#4 0x00007fffe89d24cd in nm_modem_deactivate (self=0x555555aba1b0 [NMModemBroadband], device=device@entry=0x555555ab8c20 [NMDeviceModem]) at nm-modem.c:1164
#5 0x00007fffdbd73022 in deactivate (device=0x555555ab8c20 [NMDeviceModem]) at nm-device-modem.c:455
#6 0x00005555555e087b in nm_device_cleanup (self=self@entry=0x555555ab8c20 [NMDeviceModem], reason=reason@entry=NM_DEVICE_STATE_REASON_NOW_MANAGED, cleanup_type=cleanup_type@entry=CLEANUP_TYPE_DECONFIGURE)
at devices/nm-device.c:10392
#7 0x00005555555e0ffd in _set_state_full (self=self@entry=0x555555ab8c20 [NMDeviceModem], state=state@entry=NM_DEVICE_STATE_UNAVAILABLE, reason=reason@entry=NM_DEVICE_STATE_REASON_NOW_MANAGED, quitting=quitting@entry=0) at devices/nm-device.c:10804
#8 0x00005555555e1a16 in nm_device_state_changed (self=self@entry=0x555555ab8c20 [NMDeviceModem], state=state@entry=NM_DEVICE_STATE_UNAVAILABLE, reason=reason@entry=NM_DEVICE_STATE_REASON_NOW_MANAGED)
at devices/nm-device.c:11029
Fixes: 21b50c59ce
Since commit 4c2410bc92 ("platform: extend NMIPConfigSource to
preserve the rtm_protocol field") the rt_source field of a
NMPlatformIP{4,6}Route contains the RTPROT value read from
kernel. Update checks on route source, otherwise existing routes are
not picked up when a generated connection is created, breaking the
connection matching.
Fixes: 4c2410bc92
When a configuration is replaced by another with different metadata,
disconnect signals and clear @best_conf pointers. Also, the check in
remove_ip_config() was wrong.
Fixes: 8e6d442477
Fixes: 570d73979b
To allow the execution of asynchronous actions before the system is
suspended, add a mechanism for delaying the drop of inhibitor lock.
Clients can supend the suspension by calling inhibit_take() in their
handler for SLEEPING signal and use inhibit_release() later when they
are done.
We take a "delay" type inhibitor lock, which means that the system
will proceed anyway after a certain amount of time.
Co-Authored-By: Thomas Haller <thaller@redhat.com>
Use the ipvx.dns-priority when sorting the array of
configurations. When a negative value is found, all following entries
with a greater value are skipped.
Fall back to system default value for ipvx.dns-priority when it's zero
in the setting. For VPNs the default value is 50; for other
connections is 100, but it depends also on the content of
[connection*] sections in NetworkManager.conf.
In a following commit configurations will be ordered by their
priority; arrange them in a single array to make this simpler. Also,
instead of using g_object_set_data() to store metadata, introduce a
NMDnsIPConfigData structure.
If the initial hash includes the global configuration, every update
attempt will be skipped because the configuration never changes, and
resolv.conf will never be updated. Instead, use a NULL global
configuration to compute the hash and force an initial update.
It's not enough to consider IF_LOWER_UP flag. Instead,
the important flag is actually IF_UP.
Actually, I suspect that IF_LOWER_UP is not needed. But for
now leave it, in order not to break something.
This is especially important, because changing MTU takes the
link down for a moment. Taking a link down deletes IP routes and
IPv6 addresses. Thus, when the link comes up again, we must restore
them.
Otherwise, we don't call merge_and_apply() until the next DHCP lease
(or possibly never in case of static addressing).
https://bugzilla.redhat.com/show_bug.cgi?id=1309899
nm_device_set_ip4_config() is called during cleanup and
from ip4_config_merge_and_apply(). The latter, has several
call sites.
It's not easy to track whether we called set_ip4_config with
or without commit (and if we call it without commit, we might
not see a logging line at all).
(same for nm_device_set_ip6_config()/ip6_config_merge_and_apply()).
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.
... and make the structs NMAuthSubject and NMAuthSubjectClass
opaque types.
I don't want to do this for all our types, only for a few prominent
GObject instances that we create a lot and that are really not expected
to ever be subclassed.
NMAuthSubject is such a candidate. It is really a very simple object
containing a few information bits about the authentication request.
It is not ever expected to be extended/inherited or become more
complex. No need to do a full-fledged private-data implementation.
Usually, our _GET_PRIVATE() macros cast away the const-ness of
the self argument -- also because they cannot do any better in
plain (gcc) C.
Now it is possible to preserve const-ness, it seems more correct to do so.
After all, the const should also help us not modifying arguments that are
not intended to be modified.
Although, the more important use of const is to signal that a function
promises not to modify an argument, like in memcpy(void*,const void*)
it's immediately clear which is source and destination. In C, a const
is anyway not enforcable, but can show intent.
Likewise for NM_IP6_CONFIG_GET_PRIVATE() and NMIP6Config.
We don't add such wrappers anywhere else, and I think they are not
desired style.
Also, keep the signal-id in a "gulong session_changed_id", instead of
guint.
With GObject, the object structure and class structure must be public
to be able to inherit from the type. As NMIP4Config is not inherited
(final), we don't need that and we don't expect ever needing that for
this type.
Already now, we want to have the priv pointer directly accessible via
self->priv. The main reason is improved debugging, another reason
is faster lookup.
Now with the struct private, we can directly embed the private data
inside NMIP4Config. This avoids storing the private data outside separately
inside the GObject which involves a small overhead.
It becomes more attractive to do so, as every NMDevice has a multitude of
these NMIP4Config instances.
And likewise for NMIP6Config.
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.
