You can't g_array_insert_val() to an index that's beyond the end
of the array, which was happening if the user tried to set the
band list to "any":
mmcli -m 0 --set-bands=any
Just use g_array_append_val() instead.
==5618== Invalid read of size 2
==5618== at 0x4A0A158: memcpy@GLIBC_2.2.5 (mc_replace_strmem.c:881)
==5618== by 0x326201D8FB: g_array_insert_vals (string3.h:57)
==5618== by 0x442EFB: mm_iface_modem_set_bands (mm-iface-modem.c:1982)
==5618== by 0x44307E: handle_set_bands_auth_ready (mm-iface-modem.c:2100)
==5618== by 0x326386DFF6: g_simple_async_result_complete (gsimpleasyncresult.c:775)
==5618== by 0x4358E3: authorize_ready (mm-base-modem.c:1300)
==5618== by 0x326386DFF6: g_simple_async_result_complete (gsimpleasyncresult.c:775)
==5618== by 0x326386E0F8: complete_in_idle_cb (gsimpleasyncresult.c:787)
==5618== by 0x3262047A54: g_main_context_dispatch (gmain.c:2715)
==5618== by 0x3262047D87: g_main_context_iterate.isra.24 (gmain.c:3290)
==5618== by 0x3262048181: g_main_loop_run (gmain.c:3484)
==5618== by 0x426235: main (main.c:142)
==5618== Address 0x10a7ea74e is not stack'd, malloc'd or (recently) free'd
==5618==
==5618==
==5618== Process terminating with default action of signal 11 (SIGSEGV)
==5618== Access not within mapped region at address 0x10A7EA74E
==5618== at 0x4A0A158: memcpy@GLIBC_2.2.5 (mc_replace_strmem.c:881)
==5618== by 0x326201D8FB: g_array_insert_vals (string3.h:57)
==5618== by 0x442EFB: mm_iface_modem_set_bands (mm-iface-modem.c:1982)
==5618== by 0x44307E: handle_set_bands_auth_ready (mm-iface-modem.c:2100)
==5618== by 0x326386DFF6: g_simple_async_result_complete (gsimpleasyncresult.c:775)
==5618== by 0x4358E3: authorize_ready (mm-base-modem.c:1300)
==5618== by 0x326386DFF6: g_simple_async_result_complete (gsimpleasyncresult.c:775)
==5618== by 0x326386E0F8: complete_in_idle_cb (gsimpleasyncresult.c:787)
==5618== by 0x3262047A54: g_main_context_dispatch (gmain.c:2715)
==5618== by 0x3262047D87: g_main_context_iterate.isra.24 (gmain.c:3290)
==5618== by 0x3262048181: g_main_loop_run (gmain.c:3484)
==5618== by 0x426235: main (main.c:142)
We don't support SIM/RUIM on CDMA devices (yet), so for now it makes
no sense to run the after-sim-unlock step on CDMA-only devices where
a SIM won't be present.
Unfortunately we don't know at this point whether there is a SIM
or not, so if the modem is a multi-mode device (implying it has a SIM
slot) and its plugin implements the modem_after_sim_unlock() hook,
the hook will still be executed and might cause an unecessary delay
when a SIM is not inserted.
Allow mm_iface_modem_update_state() receive 'MM_MODEM_STATE_FAILED', and treat
it as any other change to failed state, but with
'MM_MODEM_STATE_FAILED_REASON_UNKNOWN'.
Patch "iface-modem: fix invalid modem state consolidation" (commit
69aff6183a) incorrectly consolidates the
modem state upon the disconnection of a bearer. The modem state remains
'connected' after the last bearer is disconnected. This patch fixes
that.
Instead of a custom modem_init() step in the 'Modem' interface, just add a
sequence of port initialization commands in each port.
While enabling for the first time a non-hotplugged modem, we will issue the
port initialization commands only after having run the enabling_modem_init()
step (i.e. after ATZ usually).
This patch rearranges the initialization steps in MMIfaceModem such that
the following SIM related operations happen at the end of the
initialization:
- INITIALIZATION_STEP_UNLOCK_REQUIRED
- INITIALIZATION_STEP_SIM
- INITIALIZATION_STEP_OWN_NUMBERS
The rationale of this change is that the SIM interface of some modems
may require some time to initialize before it responds to SIM related
AT commands. By rearranging the initialization steps to execute non-SIM
related AT commands first, some of the latency for the SIM
initialization can be absorbed.
ModemManager has a bogus modem state transition from 'enabling' to 'disabled':
ModemManager[26214]: <info> Modem fully enabled...
ModemManager[26214]: <info> Modem /org/freedesktop/ModemManager1/Modem/2: state changed (enabling -> disabled)
The root cause seems to be the following:
get_current_consolidated_state() in MMIfaceModem returns
MM_MODEM_STATE_DISABLED as the default fallback value. When
mm_iface_modem_update_state() is invoked to transition the modem state from
MM_MODEM_STATE_ENABLING to MM_MODEM_STATE_ENABLED, the following code can
potentially cause the final state to be MM_MODEM_STATE_DISABLED instead.
/* Enabled may really be searching or registered */
if (new_state == MM_MODEM_STATE_ENABLED)
new_state = get_current_consolidated_state (self);
https://code.google.com/p/chromium-os/issues/detail?id=38173
This patch modifies MMIfaceModem to schedule the periodic signal quality
check with a period of 3s instead of 30s (up to 5 periods) initially
until a non-zero signal quality value is obtained and then switch back
to the 30s period.
The logic to handle the lock information (current lock and unlock retry count)
wasn't handling all possible cases properly, e.g.:
* When PIN is incorrectly entered too many times, a SIM-PUK error may happen.
In this case we need to directly assume SIM-PUK is the current lock (some
modems, like Option HSO ones, would incorrectly reply SIM-PIN if CPIN? asked
just after the SIM-PUK error).
* After every operation acting in SIM locks, we need to update the current
unlock retry count.
This change tries to cover those cases, by:
* The logic to check current lock is extended to also load the unlock retry
count when needed.
* Whenever a SIM-PUK error happens in the SIM operations, we directly assume
that SIM-PUK is required, without re-asking CPIN?.
* The overall logic of lock checking is now handled by a state machine, which
is much easier to understand.
It is not the Modem interface the one notifying about the 'enabling->enabled'
transition, it's the BroadbandModem directly doing it, covering all the enabling
sequences of all the interfaces.
It is not the Modem interface the one notifying about the 'disabling->disabled'
transition, it's the BroadbandModem directly doing it, covering all the
disabling sequences of all the interfaces.
Before the change, the client application loses all new property change
notifications in the interface object:
$ sudo mmcli -m 0 -w
/org/freedesktop/ModemManager1/Modem/0: Initial state, 'locked'
/org/freedesktop/ModemManager1/Modem/0: State changed, 'locked' --> 'initializing' (Reason: None or unknown)
After the change, it doesn't:
$ sudo mmcli -m 0 -w
/org/freedesktop/ModemManager1/Modem/0: Initial state, 'locked'
/org/freedesktop/ModemManager1/Modem/0: State changed, 'locked' --> 'initializing' (Reason: None or unknown)
/org/freedesktop/ModemManager1/Modem/0: State changed, 'initializing' --> 'disabled' (Reason: None or unknown)
/org/freedesktop/ModemManager1/Modem/0: State changed, 'disabled' --> 'enabling' (Reason: User request)
/org/freedesktop/ModemManager1/Modem/0: State changed, 'enabling' --> 'registered' (Reason: User request)
/org/freedesktop/ModemManager1/Modem/0: State changed, 'registered' --> 'disabling' (Reason: User request)
/org/freedesktop/ModemManager1/Modem/0: State changed, 'disabling' --> 'disabled' (Reason: User request)
In QMI modems the logic behind supported and current bands is completely
separated in different services (DMS vs NAS). Actually, the list reported by NAS
as current band preferences seems to include more values than the ones reported
by DMS as supported bands (e.g. CDMA bands are reported even if the firmware
image is GSM/HSPA only).
So, just clean up the list of current preferred bands so that no more than those
given as supported is used.
We do need to specify which is the primary port being used for controlling the
modem. This allows us to match the device with an already existing bluetooth
device in NetworkManager.
The interfaces usually retrieve objects (e.g. skeletons) from the Modem object
using g_object_get(), but we didn't make sure that these objects were actually
valid before using them.
This should clean up errors happening when the modem gets unplugged and still
some actions are ongoing.
Should fix https://bugzilla.gnome.org/show_bug.cgi?id=685933
Both the ModemManager daemon and the mmcli will now include `libmm-glib.h' only.
We also handle two new special `_LIBMM_INSIDE_MM' and `LIBMM_INSIDE_MMCLI'
symbols, which if included before the `libmm-glib.h' library allow us to:
* Don't include the libmm-glib high level API in the ModemManager daemon, as
the object names would clash with those in the core.
* Define some of the methods of helper objects to be included only if compiling
ModemManager daemon or the mmcli.
The power-down command defined by the plugin will be run *only* after having
checked for current and modem capabilities, as plugins (e.g. Sierra) may have
different commands for that depending on whether they are 3GPP or 3GPP2.
We do not reuse the 'modem_power_down' callback from the disabling sequence, as
some plugins really behave pretty badly with this (e.g. Samsung CFUN=4 may take
up to 30s to complete). So, we let plugins use the power-down command when
disabling but avoid launching it during init.
In order to ease the life for clients listening to the 'state-changed' signal,
the change in the 'state' property in the DBus interface skeleton is flushed
right away, before emitting 'state-changed'. By doing this we make sure that
the 'state-changed' callbacks in the clients are able to see exactly the same
current state in the modem proxy.
When the modem gets unplugged, or system gone into suspend, we start losing the
modem ports one by one. When the last is lost, we trigger the disposal of the
modem (we call g_object_run_dispose() and then we call the main-reference
unref()). So, if we end up losing all ports while the connection sequence was
being run, we would end up in this situation, where we try to disconnect the
bearers (the bearer and modem objects are still valid, as we have references
around, but the list of bearers won't be available any more in the modem object
as it was cleared in the modem dispose().
Thread 0 *CRASHED* ( SIGSEGV @ 0x00000000 )
0x7f5cdbd5cda0 [ModemManager] - mm-bearer-list.c:163] mm_bearer_list_foreach
0x7f5cdbd6a4bd [ModemManager] - mm-iface-modem.c:110] bearer_status_changed
0x7f5cdbad0903 [libgobject-2.0.so.0.3000.2] - gclosure.c:774] g_closure_invoke
0x7f5cdbae1dbb [libgobject-2.0.so.0.3000.2] - gsignal.c:3272] signal_emit_unlocked_R
0x7f5cdbaeac82 [libgobject-2.0.so.0.3000.2] - gsignal.c:3003] g_signal_emit_valist
0x7f5cdbaeae5e [libgobject-2.0.so.0.3000.2] - gsignal.c:3060] g_signal_emit
0x7f5cdbad3876 [libgobject-2.0.so.0.3000.2] - gobject.c:925] g_object_dispatch_properties_changed
0x7f5cdbad5ceb [libgobject-2.0.so.0.3000.2] - gobjectnotifyqueue.c:132] g_object_notify_by_pspec
0x7f5cdbd56b08 [ModemManager] - mm-bearer.c:112] bearer_update_status
0x7f5cdbd56ffd [ModemManager] - mm-bearer.c:393] disconnect_ready
0x7f5cdbbcc676 [libgio-2.0.so.0.3000.2] - gsimpleasyncresult.c:749] g_simple_async_result_complete
0x7f5cdbbcc788 [libgio-2.0.so.0.3000.2] - gsimpleasyncresult.c:761] complete_in_idle_cb
0x7f5cdb7cff44 [libglib-2.0.so.0.3000.2] - gmain.c:2441] g_main_context_dispatch
0x7f5cdb7d0597 [libglib-2.0.so.0.3000.2] - gmain.c:3089] g_main_context_iterate
0x7f5cdb7d0b51 [libglib-2.0.so.0.3000.2] - gmain.c:3297] g_main_loop_run
0x7f5cdbd4e331 [ModemManager] - main.c:150] main
0x7f5cdb1ea41c [libc-2.15.so] - libc-start.c:234] __libc_start_main
0x7f5cdbd4de48 [ModemManager] + 0x00019e48]
Reported by Ben Chan <benchan@google.com>
Whenever we query current unlock required status and we get that we're unlocked,
we'll launch the after-sim-unlock step so that we try to ensure that the SIM is
ready.
Different ports of the same modem may get handled by different drivers. We
therefore need to provide a list of drivers (new `Modem.Drivers' property with
signature 'as') instead of just one (removed `Modem.Driver' property with
signature 's').
$ sudo mmcli -m 0 | grep drivers
| drivers: 'qcserial, qmi_wwan'
In practice, it may take longer time for a SIM to become ready when the
modem interface tries to use AT+CPIN? to determine if the SIM is
PIN-locked. This patch increases the number of trials for PIN check to
address the issue.
Instead of hardcoding the logic to decide which ports are open or closed in the
different steps, we now let the subclasses of MMBroadbandModem to do that
themselves.
We now provide:
* initialization_started() and initialization_stopped(): the generic
implementation does the serial port open/close in these steps.
* enabling_started(): the generic implementation does the serial port opening
here. The serial ports are kept open as long the modem is in enabled state.
* disabling_stopped(): the generic implementation does the serial port closing
here.
When the interface is shut down the skeleton object no longer exists. Given that
we're allowing this actions from outside the interface, we should be safe and
don't assume that the caller knows exactly the state of the interface.
