There's no encoding information about 8-bit SMS messages,
and they are often binary things like ringtones or voicemail
indicator commands. Since there's no point to our parsing
them just let clients deal with it.
MM implements the DBus properties interface and of course that
requires some XML on our side for dbus-glib. But we shouldn't
install that along with our ModemManager-specific XML.
USB interface 0 isn't a serial interface; it's probably a custom
Nokia PhoNet port or a custom Icera pseudo-ethernet port. But
it's not a CDC-ACM serial port, at least on the CS17.
Reported by Uwe Geuder.
decode.py will read SniffUSB logs of communication with
QMUX or WMC speaking devices. It will dump the packets
in both hex and ASCII. If you know something about the
device then you can tell it to decode the packets. For
example, we know the Pantech UML290's WMC port speaks
WMC using Bulk Transfers, so we can:
decode.py --transfer=wmc <path to sniffusb logs>
or we know the UML290's "rmnet" port speaks raw IP in
the Bulk Transfers and QMUX in the Control Transfers, so:
decode.py --control=qmux <path to sniffusb logs>
qmiprotgen.py takes a path to an Entities.txt file and
dumps out the protocol entities and services in
Python code which is used by qmux.py.
xml2ascii.py and analyze.py dump out UsbSnoopy XML logs
but these are not as usable as the SniffUSB logs (they
do not provide good direction information).
http://www.wingmanteam.com/usbsnoopy/http://www.pcausa.com/Utilities/UsbSnoop/
Various bits of the code didn't check if response was valid
or not during error conditions, and when an error occurs
sometimes it'll be NULL (since not all errors are translated
errors from the modem, some are serial or general ones). We
have to make sure we don't try to use response->str when
response doesn't exist.
Found in the generic CDMA code likely as a result of
d5d9eec2b5 but was a bug long
before that commit happened anyway.
Change the error handling to be a bit more like what appears to have
been intended: if constructing the regex fails, report an error and
return. The existing code looked like it was set up to do this, but
wasn't quite wired together, and had process-terminating calls
(g_error()) followed by other code.
Change-Id: I4a7cee8fe01291976edc2e343fcbeb73e882f20b
First, arrange for received/complete signals to be sent by calling
cmti_received_has_sms() with the message properties even if the
message isn't complete yet.
Second, make the operation of the List command's multipart message
handling independent of message order by doing one pass to insert the
messages into the cache and second pass to retrieve the complete messages.
Change-Id: I3dcae940d71aec3ddb65c508675f710d1567b0e2
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]
