ZTE MF683

[Bjørn Mork]

"Shawn J. Goff" <shawn7400 at gmail.com> writes:

> I previously said we were using little-endian; I was wrong; it's big-endian.
>
> Looks like it's qmi; 

Yup.


> I did it twice because the first time, it gave me
> other stuff before the 01120080... response:
>
> c2890e20 811070979 S Ii:1:005:7 -115:16 64 <
> c2890d20 811071305 S Co:1:005:0 s 21 00 0000 0005 000c 12 = 010b0000
> 00000001 27000000
> c2890e20 811073223 C Ii:1:005:7 0:16 8 = a1010000 05000000
> c2890da0 811073260 S Ci:1:005:0 s a1 01 0000 0005 0200 512 <
> c2890e20 811073300 S Ii:1:005:7 -115:16 64 <
> c2890d20 811075108 C Co:1:005:0 0 12 >
> c2890e20 811075772 C Ii:1:005:7 -2:16 0
> c2890da0 811075864 C Ci:1:005:0 0 12 = 010b0080 00000200 27000000

Yes, you get some of these QMI_CTL SYNC (0x0027) messages.  We don't
really know why the devices send these, but they do.

> And here is the assertion failure:
..
> c2890da0 1071844090 C Ci:1:005:0 0 39 = 01260080 03010201 0020001a
> 00020400 00000000 0102009a 05110400 01006605
> **
> ERROR:qmi-utils.c:72:qmi_utils_read_guint8_from_buffer: assertion
> failed: (*buffer_size >= 1)
> Aborted
> # c2890e20 1071967308 C Ii:1:005:7 -2:16 0

Aleksander can probably say more about that if you can run it in the
debugger.  The last message there looks like a perfectly valid 
nas-get-signal-strength response to me:


tf 01
len 2600
ctrl 80 
sys 03
cid 01
flags 02
tid 01 00
msgid 2000
tlvlen 1a00
tlv 02: len 0400 - 00000000 = status OK
tlv 01: len 0200 - 9a05 =  0x9a dBm, radio: UMTS
tlv 11: len 0400 - 01006605 = 1 instance, rssi: 0x66, radio: UMTS

Eh, cancel that.  There is something missing here, so we don't really
know.  The usbmon length 39 is consistent with the two length fields in
the packet so I assume the end of it is just missing from the dump.
There is probably one more 7 byte TLV here which we don't see in this
dump.


Bjørn