In general we don't touch the externally set default route on devices
that use a generated-assumed connection. When the IP method is AUTO
(or DHCP), this means that we are not able to restore the default
route after a temporary expiration of the lease which removes
addresses/routes from the device.
Change this, and let NM update the default route for generated-assumed
devices using dynamic addressing.
https://bugzilla.redhat.com/show_bug.cgi?id=1265239
(cherry picked from commit 9b7f9af077)
The applied connection must describe the configuration that was
initially activated on the device. Even if the IP configuration
changes, we shouldn't reset the applied connection for devices using a
generated-assumed connection, otherwise we would lose information on
the IP method we're trying on the device.
(cherry picked from commit c84fd50287)
No need to require the caller to initialize the optional out-argument.
Otherwise we get:
(nm-connection-editor:2471): libnm-CRITICAL **: nm_utils_file_is_private_key: assertion 'out_encrypted == NULL || *out_encrypted == FALSE' failed
https://bugzilla.gnome.org/show_bug.cgi?id=763578
Fixes: 1c4f41c610
(cherry picked from commit 81499355b0)
g_file_read_link() "reads" the symbolic link. If it's a relative path,
we get a relative path which is anchored on @file. We must resolve that
to be absolute.
(cherry picked from commit 7f7e1eb60b)
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.
(cherry picked from commit 02e84ba1e8)
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
(cherry picked from commit 35a7ea77b0)
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()).
(cherry picked from commit f50e39fc98)
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
(cherry picked from commit 37827fcafa)
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
(cherry picked from commit 0b66eb298e)
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)
(cherry picked from commit 702b74c9f7)
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)
(cherry picked from commit aa0b379699)
This is required to add objects in the "Types and Values" section and
in the API index. Later, we may want to add useful content in those
empty comments.
(cherry picked from commit f1d23c32c3)
nm-core-types.h and nm-types.h contain the actual definition of types
and gtk-doc won't generate a "Implemented interfaces" section if they
are not included.
https://bugzilla.gnome.org/show_bug.cgi?id=765983
(cherry picked from commit a51a43fc84)
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.
(cherry picked from commit 0175056a6d)
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.
(cherry picked from commit 73cec4e912)
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.
(cherry picked from commit bac06c5ae6)
Just like `nmcli device connect` only allows one argument, don't allow
multiple device arguments for reapply.
Allowing multiple device names makes it more complicated to add
additional options to the command. For example, it would be useful
to have a
nmcli device reapply eth0 connection id other-connection
but when allowing multiple device names, it gets more complicated in
documentation, command line parsing and bash completion.
Note that the user can achieve a very similar outcome by using the
shell:
for DEV in eth0 eth1 eth2; do
nmcli device reapply $DEV &
done
wait
argubaly, this doesn't report the exit status properly. To properly
handle that would require more effort. Also, it is somewhat less
efficient, but well.
This is an API change, however it is very new API that probably nobody
is using much. Also, the documentation (man nmcli) didn't mention the
possibility to pass multiple device names.
(cherry picked from commit d742ea7817)
