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 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 while the same request from the UML290 looks like this: 41542a574d433d c8 7d2a 87 b8 0d 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