Like the MF627 for some reason. Also, the format appears to be
more like the DM_CMD_VERSION_INFO response where at least the
comp_date and comp_time fields are the same size as
VERSION_INFO, just with some padding between.
The first byte of the PDU is the SMSC length, but it's not
the padded SMSC length. So we need to subtract the actual
byte index of the start of the message from length of the
PDU, and since the PDU creation function knows all about
where the SMSC address stops and the message begins, just
have it return that length instead of making the callers
calculate it.
Python usually uses Unicode, but often the shell encoding
will be in UTF-8, so Python needs some help converting the
message to Unicode. Use LANG to do that if we can.
Tests that the last septet (packed in an octet by itself)
doesn't get left off the message like the old code used to
do before "core: fix some bugs in GSM7 packing code".
Making clients pass the raw GSM PDU value isn't very useful
since it's not exactly trivial to create programmatically.
Instead, let's make validity be units of 5 minutes and MM
will automatically figure out how to map that to the PDU
value.
The existing gsm_pack() had a bug where if the last
septet should be in an octet by itself, that last
octet wouldn't be added. Plus, kinda pointless to
use a GByteArray here when we already know what the
length will be through simple arithmetic.
We can also simplify the function too.
Furthermore, there weren't any testcases for starting
packing at an offset other than zero, so add one.
Log messages are enabled by LOG_CONFIG and are then reported
as unsolicited responses with code DM_CMD_LOG. Each log type
appears to have its own message format which are now being
added to log-items.h.
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
