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>
Remove an unused variable so it's more obvious what the correct value is.
Fixes live (vs. list) SMS reception on ToT.
BUG=none
TEST=Send SMS to device, see that it shows up in Chrome.
Change-Id: I9c76fb15ef229fe83672e2eee8ae37d7e6ab7b9e
Reviewed-on: http://gerrit.chromium.org/gerrit/3216
Reviewed-by: Nathan J. Williams <njw chromium org>
Tested-by: Nathan J. Williams <njw chromium org>
On a ZTE MF626, sometimes the aux port will respond only with
"ERROR" to probing commands (while the SIM is starting up) and
previously we'd lose the port because we were only looking for
valid probe responses. But if the port returns ERROR or CME ERROR
etc we know it's an AT port and that we can use it once we've
gotten the type response (CDMA or GSM) from the main port.
When connecting, and the modem isn't yet registered or denied, poll
both CS and PS registration state instead of just CS state, because
we're really more interested in PS state anyway. If at least one
of the CS and PS state checks is successful then proceed with the
connection.
It seems the Motorola Flipout with Android 2.1 doesn't like to return
configured PDP contexts via AT+CGDCONT?; it returns an error. It
seems to accept the rest of the dial sequence though, so just ignore
the error when reading existing PDP contexts.
Fix one more possible memory leak (left un-fixed by d3c2228 but not
caused by it) and ensure that modems that do want flashing get it
by default by adding the missing G_PARAM_CONSTRUCT so FLASH_OK
defaults to TRUE.
The F5521gw resets various port properties like echo when the port
is flashed, which was happening on disconnect. Since MM had already
turned of echo with ATE0, and the AT parser in-use expected no
echo, this confused MM when the port magically started echoing commands
back. We don't need flashing on the Ericsson devices because there
will always be a free AT port even if PPP is used for a secondary
PDP context, so we can just skip flashing entirely for these
devices.
Flashing is a technique to break out of the data/PPP stream and
re-enter command stream (like +++) and MM uses it in the generic
paths in various cases. But devices that don't need it (ie, ones
with at least one AT capable port that won't be used for data)
now sometimes appear to have side-effects.
The Ericsson F5521gw firmware R2A07 resets port attributes like
echo and &C and such when the port is flashed, leading to
confusion on the part of MM. Since the Ericsson devices will
always have at least one free AT port they don't need flashing
anyway.
Aleksander Morgado
Dan Williams
Nathan Williams
Thomas Tuttle
Torgny Johansson
Eric Shienbrood