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)
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)
The applied connection must have no secrets. It's unclear whether
there are any secrets at this point (possibly). To be sure, clear them.
(cherry picked from commit b52d25e129)
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.
(cherry picked from commit a47c13a7a2)
It can return NULL and makes Coverity upset:
CID 75369 (#1 of 1): Dereference null return value (NULL_RETURNS)
4. dereference: Dereferencing a null pointer ret.
(cherry picked from commit 76844c65d6)
For some device types, we use the DEVTYPE from sysfs to determine the
link type. However, the way we read from sysfs can race with device
renames and we could miss the chance to read DEVTYPE correctly.
This doesn't completely fix the sysfs race, but cures the boot-time race
with systemd renaming the device while we are initializing the link.
We ideally should use GUDev for all sysfs accesses, but that would need
some more work for this particular case as currently we need the link type
before we have an udev device instance.
https://bugzilla.gnome.org/show_bug.cgi?id=764803
Co-Authored-By: Beniamino Galvani <bgalvani@redhat.com>
(cherry picked from commit dd4d8b24da)
The notification was missing from a long time. The issue has been exposed only
now due to the c57e5a6b66 fix which properly
implemented the "startup-complete" notification substituting out of place code
which masked the bug.
(cherry picked from commit 19350c8975)
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
(cherry picked from commit 0589e659ca)
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.
(cherry picked from commit 89cf9429a7)
When mounting /proc with hidepid, we might fail to read the
start-time of the process from /proc/$PID/stat. In this case,
we should just accept a start-time of zero.
On the other side of authentication, polkit should accept a zero
start-time too.
nm_utils_get_start_time_for_pid() has other uses in NetworkManager,
mostly when killing a process from a PIDFILE or during
nm_utils_kill_process_sync(). In both these cases, this will only
succeed if we try to kill a process that also runs a root.
For processes started by the current instance, we don't care about the
PIDFILE and use nm_utils_kill_child_?sync() -- so there is no problem
with hidepid there.
https://bugzilla.gnome.org/show_bug.cgi?id=764502
(cherry picked from commit 3d505b3f87)
Pass an empty configuration file otherwise dnsmasq loads
"/etc/dnsmasq.conf".
We already allow for a config.d/ directory "/etc/NetworkManager/dnsmasq.d"
to allow the user to overwrite configuration. We don't want to consider
the global config file.
Fixes: 497a8aa5c6
(cherry picked from commit 3d3f71acec)
The 4 private fields pid, watch_id, progname and pidfile strictly
belong together. When spawning a child, we set all 4 of them and
when killing the child all get cleared. Cleanup to code to always
set those 4 fields together.
(cherry picked from commit 4d5ca7f9de)
