The introspection data specified the Send() method to return
an array of unsigned integers, presumably the indexes of the
messages just sent. But the code wasn't doing that, leading
to a crash when dbus-glib tried to interpret garbage on the
return.
The problem is that sms_send_auth_cb() gave async_call_done()
as the callback for sending the SMS, but that method just calls
dbus_g_method_return() with no return arguments. dbus-glib
interprets the arguments of dbus_g_method_return() according
to the XML introspection data, and thus it was attempting to
read the non-existent argument as an 'au' and getting garbage.
Fix that by actually returning an array of message indexes from
the SMS send code, and propagate that back to the SMS dbus
code so it can return something sensible.
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/
