Reporting errors instead of just returning permits routines like
mm-generic-gsm.c:simple_get_status() to work again, as their callbacks
get the error they are expecting. To make this work, adapt get_csq_done()
to handle a NULL response when error is set, and make sure that multiple
errors don't step on each other in the mm_callback_info_chain() sequence
created by simple_get_status().
Change-Id: Ie3a72b1ce71b7f117e8b1f3da7a406c4d2da9e02
Some modems don't allow most commands when they are PIN locked, so
the initial facility lock check errors out. Check the locks again
after the SIM is unlocked.
The property EnabledFacilityLocks on the .Modem.Gsm.Card interface
is a bit mask that indicates which of the various personalization
codes from 3GPP TS 22.022, plus the SIM PIN lock and SIM PIN2 lock,
are enabled. The set of facility locks supported by the modem is
determined at the time the modem is initialized, and the state of
each supported lock (enabled or disabled) is determined. When the
state of a lock changes, a property-change signal is sent out. Note
that ModemManager only supports enabling and disabling SIM-PIN, via
the EnablePin method on Modem.Gsm.Card.
Added a PinRetryCounts property on org.freedesktop.ModemManager.Modem.
This is dictionary that records the number of PIN tries remaining
for each of the possible PIN code types for which the modem is
capable of reporting the count. Also, these counts are kept up
to date across ChangePin and EnablePin operations, not just when
an unlock is attempted.
ModemManager currently encodes the USSD command *141*0# (for MTN South
Africa) as "AA182DA6828D00".
While this works on some modems, for example the E1820, other modems,
for example the E160, require USSD commands that are a multiple of 7
characters long to be padded with 0x0d.
Huawei Mobile Partner dashboard software for Windows encodes *141*0#
as "AA182DA6828D1A" which works on both the E1820 and the E160.
The attached patch pads the USSD command with 0x0d before encoding if
it is a multiple of 7 characters long.
Otherwise, we can schedule a main loop call to
mm_serial_port_queue_process() for an object that's about to
disappear, leading to a crash.
Change-Id: I433a76855c52536eb2b99a5ecf26ac71afe1f8bb
Rearrange the primary and secondary-port disable operations so that
there's a linear chain of callbacks rather than a second dangling
callback chain for the secondary port; it's possible for the primary
port operations to complete, and for the callback to finish and start
tearing down the entire device, before the secondary port commands
run.
Change-Id: Ia95a7eae574737cdec38b14d39786127be1b3184
Keep a local cache of SMS message fragments when we perform a List or
Get command on the modem; use this cache to reassemble fragments into
complete messages, which are then what is returned by the Get and List
DBus commands. Similarly, cause Delete to delete all known parts of a
multipart message.
While here, remove some extra whitespace in the SMS commands we send
to the modem.
Supported and Allowed modes are modified to be bitmasks of MM_MODEM_MODE values,
and preference of a specific mode is now given in the new PreferredMode
property and as an extra argument to the SetAllowedModes() call.
* Supported Modes: bitmask specifying which modes are supported by the specific
hardware. For example, a modem may only support 1G/2G/3G connections (not 4G).
* Allowed Modes: bitmask specifying which modes, of the ones Supported by the
modem, are allowed to use. For example, a modem may support 1G/2G/3G connections
but only 1G and 2G connections are allowed by the user as 3G involves more
expensive data rates.
[Allowed] ⊆ [Supported]
* Preferred Mode: specific mode which is preferred among the ones defined in
the Allowed modes bitmask. For example, a modem may allow 1G/2G/3G connections
but the user would like that if possible 2G be used, as 3G consumes too much
battery. If 2G is not possible, 3G can be used.
[Preferred] ∈ [Allowed]
Some Cinterion modems send a NUL byte before the "CONNECTED" reply to "ATD"
(only during the first ATD try anyway).
This fix will ignore any NUL byte leading the real response.
It seems that various firmwares just pass values from eg AT^SYSCFG
straight through to the firmware so it's pretty easy to map them
to the actual response here. Note that the NV mode pref item uses
a different mapping than CM state info response. Yay.
Changing the allowed bands in a modem may fail, for example if trying to set a
frequency band which is not in the bands mask reported as Supported by the modem.
Therefore, we need an explicit SetAllowedBands() method with proper error
reporting instead of making the property writable.
Changing the allowed mode of a modem may fail, for example if trying to set a
mode which is not in the modes reported as Supported by the modem. Therefore, we
need an explicit SetAllowedModes() method with proper error reporting instead of
making the property writable.
Modems which only expose a single port will not be able to update the signal
quality value while in connected mode. The signal quality value reported in this
case, while the modem is connected, will be the last signal quality value read
before the connection.
The additional boolean value proposed here in the SignalQuality property will
just say if the given signal quality was recently taken (if TRUE) or cached
some time ago (if FALSE). The time to assume the value was recently taken or not
could depend on different things, for example:
* If the modem always has an AT port, even if connected, we could directly
query the current signal quality and report the value as being fresh.
* If the modem has a single port, we could report the value as not being fresh
as soon as the modem gets in connected state.
* For modems which report the signal quality updates in unsolicited messages,
we could report the value as being fresh if the update was received in the
last minute or so.
SIM objects will be listed as independent objects in the DBus API, and the 'Sim'
property in a given modem object will specify which SIM object is in use.
In particular, g_regex_match() and g_regex_match_full() allocate a
match_info structure on both success and failure, so calling
g_match_info_free() only in the success case is insufficient.
BUG=None
TEST=Inspection
Change-Id: Iea76b5b5dc3ec48120e15601a5e2dd45322133d8
When receiving a SMS message with raw 8-bit data, sanitize it by
replacing non-ASCII characters with \xNN escape sequences. This
prevents a problem further down the line where the body of the message
is passed into DBus as a string, and DBus requires strings to be UTF-8.
BUG=chrome-os-partner:5953
TEST=Run network_ModemManagerSMS.py with the PDU from this bug.
Change-Id: Ic33a365f9a065c49a325e047e4c3f5e81450fa1f
Reviewed-on: http://gerrit.chromium.org/gerrit/8232
Reviewed-by: Eric Shienbrood <ers@chromium.org>
Tested-by: Nathan J. Williams <njw@chromium.org>
Commit-Ready: Nathan J. Williams <njw@chromium.org>
