1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
|
This document describes information about the Pantech UML290 and the WMC
protocol observed through USB packet capture and other investigation.
Pantech UML290 Notes
--------------------------------------
This device exposes 4 USB interfaces. They are, in no particular order, a
CDC-ACM compatible AT command port, a QCDM/Diag port, an WMC port, and a
raw IP network port. The modem's native command interface is the WMC port
which the Windows driver uses for all normal communication.
CDC-ACM AT Port
----------------
The modem's +GCAP response reports:
+GCAP: +CIS707-A, CIS-856, CIS-856-A, +CGSM, +CLTE1
and with recent firmware updates (L0290VWB333F.230 [Mar 15 2011 15:03:20] or
later) the device does, in fact, appear to support common IS-707-A and ETSI
27.007 GSM and LTE AT commands. This interface does support PPP data but when
PPP is used the device does not support handoffs between LTE and EVDO.
To support seamless operation of devices between LTE and EVDO Verizon has
upgraded their network to support the eHRPD protocol. Older, non-LTE capable
devices usually do not include support for eHRPD and use the standard HRPD
protocols. LTE-capable devices support both eHRPD and standard HRPD, but at
least with the UML290, connections to the 3G EVDO network using direct PPP over
the AT modem port do not use eHRPD. Thus to successfully connect to the 3G
EVDO network, the modem must be switched into standard HRPD mode by changing
the value of the NV_HDRSCP_FORCE_AT_CONFIG_I NVRAM item using the the QCDM/Diag
port and the DIAG protocol. Use of HRPD only prevents connections to the LTE
network. It is possible that connections initiated using the WMC port and
utilizing the "raw IP" network interface do not have this problem.
QCDM/Diag Port
----------------
This port is a normal QCDM/Diag port and responds to DIAG commands.
Raw IP Network Port
-------------------
This USB interface is the normal network interface port the device uses in
Windows for network communication. It appears to operate in a "raw IP" mode
where raw IP packets are sent and received over USB with no additional framing
or encapsulation. The IPv4 and IPv6 addresses for the interface are determined
using WMC commands on the WMC port, not through the AT command port. The AT
command port only supports PPP-based communication. More information about the
"raw IP" mode may be available in the Qualcomm CodeAurora SMD/QMI drivers which
implement a "raw IP" network communication mode for various MSM7xxx chipsets
used in Android devices.
WMC Port
-----------
This port accepts and responds to WMC protocol requests. Instead of using plain
WMC however, requests are prefixed with the string "AT*WMC=" and terminated with
a newline (0x0D) character instead of the normal WMC frame termination
character (0x7E). The data in between is normal binary WMC data, except that
all bytes less than 0x20 are escaped using normal HDLC/PPP escaping while a
normal WMC request would only escape the special HDLC/PPP characters of 0x7E and
0x7D. Thus a UML290 request looks like this in hexadecimal:
41542a574d433dc87d2a87b80d
This "AT"-style framing has not been observed on other devices.
WMC Protocol Framing
--------------------
The protocol is a request/response style protocol though unsolicited responses
are sometimes sent from the modem to the host. There does not appear to be any
sequence numbering in either the request or response packets. WMC packets
always begin with the frame start marker (0xC8). The second byte is the command
number, followed by the frame's data. The frame ends with a three-byte trailer
including a CRC-16 and a frame termination marker which differs between devices.
Most older devices use the standard HDLC/PPP frame termination marker (0x7E),
while some others (UML290) use a different termination marker as described
below. Thus a normal WMC packet looks like this:
0xC8 <command number> <data> <CRC-16> 0x7E
The entire frame (exclusive of the termination marker) is escaped using standard
HDLC/PPP escaping mechanisms to ensure that the bytes 0x7E and 0x7D never appear
in the packet. Some devices (UML290) escape more than the standard HDLC escape
characters.
Frames can span multiple USB packets. This behavior has been observed with the
PC5740 in various responses, in which case the frame is simply split up between
USB packets. It has also been observed with some UML290 requests, where it
appears that in addition to splitting the frame, each segment after the first
is prefixed with 0x20.
For example, a split response from a PC5740:
* c8 06 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 00 00 00 00 ................
...
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ...............
* 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
...
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ...............
* 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
...
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ...............
* 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
...
00 00 00 01 ....
and an split request from a UML290:
* c8 56 86 02 00 00 00 00 00 00 39 30 30 30 38 30 .V........900080
...
00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..............
* 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ...............
...
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
* 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ...............
...
00 00 00 00 00 00 00 00 00 00 5b 1c 0d ..........[..
Requests
---------------
Requests are usually short, often only 4 or 5 bytes long, including the frame
start marker (0xC8), the command number, the 16-bit CRC, and the frame termination
marker. Requests almost always receive a response from the modem containing the
same command number.
The UML290 uses different "AT"-style framing of requests, prefixing the
request with "AT*WMC=" and using a frame termination marker of 0x0D instead
of the standard 0x7E. The UML290 also uses a different CRC-16 initial seed of
0xAAFE instead of the standard 0xFFFF used on other devices and with HDLC
framing in general. For added lolz the UML290 HDLC-escapes all control
characters in the request in addition to the standard 0x7D and 0x7E characters
escaped in HDLC.
Thus a normal WMC request (from a PC5740) looks like this:
c8 0a 77 a4 7e
<frame start> <cmd no> <CRC-16> <terminator>
while the same request from the UML290 looks like this:
41542a574d433d c8 7d2a 87 b8 0d
<AT*WMC=> <frame start> <cmd no> <CRC-16> <terminator>
Thus after removing all framing and escaping, this WMC request is a single
byte (0x0A) which indicates the command number of the request.
WMC Responses and Unsolicited Messages
--------------------------------------
Responses begin with the WMC frame start marker (0xC8) and end with the standard
HDLC/PPP frame terminator (0x7E) in all observed cases, even on the UML290.
The data in between is HDLC/PPP escaped and there is a CRC-16 before the frame
terminator. Not all devices use the same CRC-16 calculation however; the
UML290 always uses a CRC-16 of 0x3030, while the PC5740 includes a valid CRC-16
using a standard polynomial of 0x8408 and an initial seed of 0xFFFF. Responses
may span multiple USB packets if they are large enough, but the frame terminator
provides a convenient mechanism for detecting when the frame is complete.
A standard WMC response (from a UML290) looks like this:
c80d0000000030307e
which translates to:
c8 0d 00 00 00 00
WMC Command Numbers
-------------------
These command numbers have been observed and minimally investigated:
0x06: request device information, including manufacturer, model, firmware
revision, hardware revision, MCC/MNC, serial number
0x0A: request IP configuration when connected (IPv4 and IPv6) on the UML290; may
include elapsed connected time or traffic byte counts too. Request has
been observed on the PC5740 but is significantly shorter.
0x0B: get status including operator name, RSSI dBm, and possibly registration
status
0x13: retrieve SMS messages
0x4D: appears to request EPS bearer configuration; response includes the APN
|
