Re: Re:

On Thu, 2013-05-16 at 12:39 -0500, Dan Williams wrote:
On Thu, 2013-05-16 at 19:18 +0200, Aleksander Morgado wrote:
On 05/16/2013 07:05 PM, Dan Williams wrote:
What's bizarre is that a Gobi 1k with really, *really* old QMI (2009)
works just fine with the exact same command sequence.  So it can't
really be related to old vs. new QMI version, just that some devices
with some versions of WMS perhaps want a specific TLV?

The only TLV that we don't pass to List Messages is the one specifying
which message tags you want to query (e.g. I want only
QMI_WMS_MESSAGE_TAG_TYPE_MT_READ). When that TLV is not set, the modem
should return all messages. Maybe the modem really wants that TLV, and
if so, we would need to loop querying for all 4 known tags for each
message store.
Yeah, that's the problem.  Setting that TLV makes the command return
"Success" on the ADU960s, but I'm not able to actually *see* any
messages using MT_READ or MT_NOT_READ.  Also, when sending an SMS, all I
get from the ADU960s is the "Transfer Route MT Message" indication,
which MM currently ignores.  That data looks like it contains the PDU,
right?  Maybe this firmware simply can't store the message to NV so it
indicates it to the host and then discards it, and that's why it doesn't
show up in SM/NV storage?

Not even the SM storage? :/ Did you try to create a SMS, store it in SM
storage (--store-in-storage=sm) and then --send it?

Adding MO_SENT to WMS List Messages for both NV and UIM storage during
the Enable step return Invalid Argument.  Sending failed with
Wms.MessageDeliveryFailure probably becuase I didn't specify an SMSC
yet.  Also, I get this when sending, with git master MM and mmcli:

ModemManager[8061]: <debug> [1368725795.039761]
signal_strength_get_quality_and_access_tech(): Signal strength (gsm):
-90 dBm
ModemManager[8061]: <debug> [1368725795.039805]
signal_strength_get_quality_and_access_tech(): Signal strength: -90 dBm
--> 38%
ModemManager[8061]: <info>  [1368725795.039959] [mm-iface-modem.c:976]
update_signal_quality(): Modem /org/freedesktop/ModemManager1/Modem/1:
signal quality updated (38)
ModemManager[8061]: <debug> [1368725798.674860] [mm-sms.c:180]
generate_submit_pdus():   Processing chunk '0' of text with '10' bytes

(ModemManager:8061): GLib-CRITICAL **: the GVariant format string `(ub)'
has a type of `(ub)' but the given value has a type of `(uv)'

(ModemManager:8061): GLib-CRITICAL **: g_variant_get: assertion
`valid_format_string (format_string, TRUE, value)' failed
ModemManager[8061]: (mm-sms.c:92):get_validity_relative: code should not
be reached

(ModemManager:8061): GLib-CRITICAL **: g_variant_unref: assertion
`value != NULL' failed
ModemManager[8061]: <debug> [1368725798.675965] [mm-sms.c:210]
generate_submit_pdus(): Created SMS part for singlepart SMS
ModemManager[8061]: <debug> [1368725798.676255] [mm-sms-part.c:947]
mm_sms_part_get_submit_pdu(): Creating PDU for part...
ModemManager[8061]: <debug> [1368725798.676311] [mm-sms-part.c:1032]
mm_sms_part_get_submit_pdu():   using GSM7 encoding...
ModemManager[8061]: <debug> [1368725798.676372] [mm-sms-part.c:1095]
mm_sms_part_get_submit_pdu():   user data length is '10' septets
(without UDH)
ModemManager[8061]: [/dev/cdc-wdm1] Sent message...

Specifying an SMSC still gives me Wms.MessageDeliveryFailure
unfortunately.  Trying to send a message in text mode after verifying
that the SMSC is correct also fails with CMS ERROR: 500.  So I really
have no idea whether the ADU960s can actually send text messages *at
all*.  Doesn't seem like it, but we always knew the 960s was braindead.

For the E398, perhaps it can read messages, but it still needs the


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]