DokuWiki

https://osmocom.org/projects/quectel-modems/wiki/QMI

QMI is a binary protocol designed to replace the AT command based communication with modems, and is available in devices with Qualcomm chipsets from multiple vendors (Novatel, Huawei, Sierra Wireless, ZTE… and of course Qualcomm itself).
QMI 는 AT 커맨드 기반의 모뎀 통신을 대체하기 위한 바이너리 프로토콜이다. QMI 는 퀄컴 칩셋을 탑제한 단말에서 사용 가능하다.

The protocol defines different ‘services‘, each of them related to different actions that may be requested to the modem. For example, the ‘DMS’ (Device Management) service provides actions to load device information; while the ‘NAS’ (Network Access) service provides actions to register in the network. Similarly, other services will allow the user to request data connections (WDS), setup GPS location reporting (PDS), or manage internals of the user identity module (UIM service). The user needs to handle the creation of ‘clients’ for those services by allocating/deallocating ‘client IDs’ using the generic always-on ‘control’ (CTL) service.
프로토콜은 'services' 들로 이뤄져 있고, 이는 모뎀에 각기 다른 요청을 보내는것과 관련되어 있다. 예를 들어 'DMS' (Device Management) 서비스는 단말의 정보를 로드하는 기능을 제공한다. 반면에 'NAS' (Network Access) 는 네트웍에 등록하는 기능을 제공한다. 유사하게, 데이터 연결을 하거나(WDS), GPS 위치를 가져오거나(PDS), 사용자 신분확인 모듈 (UIM service) 등 도 있다. 사용자는 'control' (CTL) 서비스를 통해서 'client IDs' 를 할당/해제함으로서 서비스들에 대한 'clients' 를 만들어서 서비스를 핸들링 할 수 있다.

Each service in the protocol defines ‘Request and Responses‘ as well as ‘Indications‘. Each pair of request/response has a maching ID which lets the user concatenate multiple requests and get out-of-order responses that can be afterwards matched through the common ID. Indications arrive as unsolicited messages, sent either to a specific client or as a broadcast message to all the clients of a given service. Usually the user needs to request the enabling of the indications to receive via some request/response.
각 서비스는 'Request and Responses' 와 'Indications' 로 정의되어 있다. 각각의 reuqest/response 짝은 ID 가 있어서, 사용자가 합쳐 보낸 여러개의 request에 대해 비 순차 response가 오더라도 ID 를 통해 request/response 를 매칭할 수 있다. indications 는 (사용자 요청 없이)임의의 순간에 특정 client 나 혹은 브로드캐스팅을 통해 (특정 서비스의) 모든 client 에게 보내진다. 보통 사용자가 어떤 request/response 처리에 대한 indication 이 올라오도록 하려면, indication 을 받겠다(enabling)는 request 를 보내야 한다.

Finally, each message in the protocol defines a set of input (in requests) and output (in responses and indications) arguments, which we name as TLVs. Some of these are defined to be mandatory, others are optional, and others are only mandatory if some other argument is available and has a given value. For example, some output arguments in response messages are only mandatory if the result of the response (given as a TLV) is SUCCESS.
마지막으로, 프로토콜의 메세지들은 (request 상의) 입력 과 (response 와 indication 상의) 출력 인자(arguments) 로 정의된다. 이는 다른말로 TLV 라고도 한다. 이들중 몇몇은 필수적이며, 어떤것들은 특정 인자가 주어졌을때만 필수적이고, 전적으로 선택적인 것들도 있다. 예를들어, 몇몇 response 의 인자는 response 의 결과(TLV 에 위치함)가 SUCCESS 일때만 의미가 있다.

The QMI protocol defines different services, each of them related to different actions that may be requested from the modem. For example, the DMS (Device Management) service provides actions to load device information, the NAS (Network Access) service provides actions to register in the network, and the WDS (Wireless Data) service allows setting up IP connections. Before using a service, the user needs to handle the creation of clients for those services by allocating/deallocating client IDs using the generic always-on CTL (control) service.

Each service in the protocol defines Requests and Responses as well as Indications. Each pair of request and response has a matching ID which lets the user concatenate multiple requests and get out-of-order responses that can be matched through the common ID afterwards. Indications arrive as unsolicited messages, sent either to a specific client or as a broadcast message to all the clients of a given service.

Finally, each message in the protocol defines a set of input (in requests) and output (in responses and indications) arguments, specified as Type-Length-Value (TLV) fields. Some of these are defined to be mandatory, others are optional, and others are only mandatory if some other argument is available and has a given value. The Type of the field defines not only which field it is, but also the format of the value to be expected (e.g. an integer, or a string, or some other supported format).

Just this level of organization outlined in the previous paragraphs makes the communication with the modem much more clear, as the messages are transferred in an organized way and are self-contained packs of information with a predefined format. So, even if more complex, it is far more powerful and less error-prone than sending and receiving text-based AT strings via a serial port.

This protocol is easily accessible in recent enough Linux kernels (>= 3.4), through the cdc-wdm and qmi_wwan drivers. Once these drivers are in place and the modem gets plugged in, the kernel will expose a new /dev/cdc-wdm device which can talk QMI, along with a wwan interface associated to each QMI port.
이 프로토콜은 최근의 리눅스 커널 (>= 3.4) 에서 cdc-wdm 및 qmi_wwan 드라이버를 통해 쉽게 접근할 수 있다. 드라이버가 로드되고, 모뎀이 연결되면, 커널에서 /dev/cdc-wdm 디바이스를 만들어 준다. 이 경로를 통해 각 QMI 포트에 연결될 wwan 인터페이스에 QMI 통신을 할 수 있다.

In order to handle the issue, upstream kernel developers took a fully different approach and developed instead a new ’qmi_wwan’ driver, simpler in orders of magnitude and much easier to maintain, while leaving all the complex logic to user-space processes, which are usually more flexible and where it is easier to change behavior or fix errors. This new driver has been available since Linux 3.4.
이 문제를 해결하기 위해 업스트림 커널 개발자는 전혀 다른 접근 방식을 취해 새로운 qmi_wwan 드라이버를 개발했습니다. 이 드라이버는 모든 복잡한 논리를 사용자 공간 프로세스로 남기면서 크기가 더 간단하고 유지 보수가 훨씬 간단합니다. 보통보다 유연하고 행동을 바꾸거나 오류를 수정하는 것이 더 쉽습니다. 이 새로운 드라이버는 Linux 3.4부터 사용할 수 있습니다.

This conflict between kernel drivers is uncommon because of how the QMI protocol is defined. It’s harder to draw the line between what should be kernel or user space based tasks. The following sections try to detail where that line was drawn in both approaches.
커널 드라이버 간의 이러한 충돌은 QMI 프로토콜이 정의 된 방식 때문에 드문 경우입니다. 커널 또는 사용자 공간 기반 작업 사이에 선을 그리는 것이 어렵습니다. 다음 섹션에서는 두 가지 방법 모두에서 그 행이 그려진 곳을 자세히 설명하려고합니다.

Since Linux 3.4, the qmi wwan driver has been available in the upstream Linux releases. Being a driver maintained within the upstream tree means that none of the problems exposed for GobiNet are applicable, so:
Linux 3.4부터 qmi wwan 드라이버는 업스트림 Linux 릴리스에서 사용할 수 있습니다. 업스트림 트리 내에서 드라이버를 유지한다는 것은 GobiNet에 노출 된 문제가 전혀 적용되지 않는다는 것을 의미합니다.

• Users will get the driver already available for the exact kernel they are using.
• Most distributions already enable the qmi wwan driver in their default builds.
• The Linux tree contains always the latest sources for the latest kernel. There are no conditional code segments with path ways for separate versions of older kernels - which tends to add complexity and a maintenance burden. This keeps the code leaner and cleaner generally speaking.
• The qmi wwan driver supports multiple QMI capable devices, regardless of which manufacturer produced them. The driver takes care of detecting the USB layout and gathering the correct endpoints from the correct interfaces. Therefore, there is no need for vendor-maintained versions of the driver.

Needless to say that the qmi wwan driver gets updated with new supported devices soon after being released. Usually users with new modems will report the new VID/PIDs to use, or even manufacturers will notify the Linux kernel community about the new devices before even being sold to the public.

The qmi wwan is very similar to the GobiNet driver from an architectural point of view (see Figure), which is obvious as the task of both drivers is to provide both a control and data interface in userspace.

QMI over USB basically uses CDC-WDM messages for the transport, and since the kernel already has code for that, the qmi wwan driver fully relies on the generic cdc-wdm driver to manage the CONTROL and INTERRUPT endpoints.
USB를 통한 QMI는 CDC-WDM 메시지를 전송에 기본적으로 사용하며, 커널에 이미 코드가 있으므로 qmi wwan 드라이버는 CONTROL 및 INTERRUPT 끝점을 관리하기 위해 일반 cdc-wdm 드라이버를 전적으로 사용합니다.

This is possible because, as explained earlier, the USB communication is done using SendEncapsulatedCommand and GetEncapsulatedResponse requests as defined by the CDC USB class. The cdc-wdm driver supports the WMC Device Management functionality of cell phones compliant to the CDC WMC specification. The result of using the cdc-wdm as a subdriver in qmi wwan is that a new /dev/cdc-wdmX character device is exposed for user-space use, which allows exchanging QMI messages.
앞에서 설명한 것처럼 USB 통신은 CDC USB 클래스에 정의 된대로 SendEncapsulatedCommand 및 GetEncapsulatedResponse 요청을 사용하여 수행되기 때문에 가능합니다. cdc-wdm 드라이버는 CDC WMC 사양을 준수하는 휴대폰의 WMC 장치 관리 기능을 지원합니다. qmi wwan의 서브 드라이브로 cdc-wdm을 사용하면 새로운 /dev/cdc-wdmX 문자 장치가 사용자 공간 사용에 노출되어 QMI 메시지를 교환 할 수 있습니다.

qmi wwan also exposes a network interface, named as wwanX because the driver gets explicitly registered with the FLAG WWAN flag. qmi wwan은 드라이버가 FLAG WWAN 플래그로 명시 적으로 등록되기 때문에 wwanX라는 네트워크 인터페이스도 제공합니다.

The qmi wwan driver knows nothing about the existence of a CTL service. It doesn’t even know that QMI is the protocol being used in the messages transferred between user-space and the modem. But leaving all the hard work to user-space doesn’t come without any cost. In particular, relaying to user-space the management of the actions performed by the CTL service means that only one single process will be able to successfully use the /dev/cdc-wdmX character device.
qmi wwan 드라이버는 CTL 서비스의 존재에 대해 아무것도 모릅니다. QMI는 사용자 공간과 모뎀간에 전송되는 메시지에 사용되는 프로토콜이라는 것을 알지 못합니다. 그러나 사용자 공간에 모든 노력을 기울이는 일은 아무런 비용없이 이루어지지 않습니다. 특히 사용자 공간에 CTL 서비스가 수행하는 작업을 관리한다는 것은 하나의 프로세스 만이 /dev/cdc-wdmX 문자 장치를 성공적으로 사용할 수 있음을 의미합니다.

The qmi wwan driver will not do any device initialization before exposing the new character and network devices in user-space. In particular, a user-space process wanting to use the QMI port will need to explicitly perform checks to see whether the device is ready to be used. Also, no connection statistics will be automati- cally gathered from the device.
qmi wwan 드라이버는 사용자 공간에서 새 문자 및 네트워크 장치를 노출하기 전에 장치 초기화를 수행하지 않습니다. 특히 QMI 포트를 사용하려는 사용자 공간 프로세스는 장치를 사용할 준비가되었는지 여부를 확인하기 위해 명시 적으로 검사를 수행해야합니다. 또한 장치로부터 자동으로 연결 통계가 수집되지 않습니다.

Following the simplicity required by the driver, and given that the driver knows nothing about the QMI protocol itself, there is no built-in mechanism to handle QMI service client allocations. Every user-space process wanting to use QMI, will need to handle the allocation and releasing of Client IDs using the CTL service.
드라이버가 필요로하는 단순성에 따라 드라이버가 QMI 프로토콜 자체에 대해 아무것도 모르는 경우 QMI 서비스 클라이언트 할당을 처리하는 기본 제공 메커니즘이 없습니다. QMI를 사용하고자하는 모든 사용자 공간 프로세스는 CTL 서비스를 사용하여 클라이언트 ID 할당 및 해제를 처리해야합니다.

Leaving the Client ID releasing task to user-space also makes it impossible to make sure that all Client IDs are released when a process ends. A well implemented program using the QMI protocol should try to perform the Client ID releases before exiting, but it is assumed that unexpected terminations of the running process will end up leaving ’leaked’ Client IDs which are never released.
클라이언트 ID 해제 작업을 사용자 공간에두면 프로세스가 끝날 때 모든 클라이언트 ID가 해제되는 것을 확인할 수 없게됩니다. QMI 프로토콜을 사용하는 잘 구현 된 프로그램은 종료하기 전에 클라이언트 ID 릴리스를 수행해야하지만 실행중인 프로세스의 예기치 않은 종료로 인해 결코 누출되지 않은 '유출 된'클라이언트 ID가 남게됩니다.

This limitation, though, provides itself a very useful feature which was not possible before with the GobiNet driver. The fact that a program can choose whether or not to release a Client ID when exiting means that it can also choose to reuse a Client ID that was maybe allocated in a previous run of the same program. From a practical point of view, the fact that the kernel doesn’t automatically release the clients when the process exits allows users to use the QMI protocol from within scripts or the command line, as there is no need to allocate or release a client in each run of the script or command line program. For most operations that can be performed through QMI, allocating/releasing a new client for each operation is a possibility, but there are some very specific use cases (e.g. WDS Start Network to setup a network connection) which require the Client ID to be kept registered all the time (or the connection will be dropped).
이 제한은 GobiNet 드라이버로는 불가능했던 매우 유용한 기능을 제공합니다. 프로그램이 종료 할 때 클라이언트 ID를 해제할지 여부를 선택할 수 있다는 사실은 동일한 프로그램의 이전 실행에서 할당되었을 수있는 클라이언트 ID를 다시 사용할 수도 있음을 의미합니다. 실용적인 관점에서 볼 때 커널이 프로세스를 종료 할 때 자동으로 클라이언트를 해제하지 않는다는 사실은 사용자가 클라이언트를 할당하거나 해제 할 필요가 없기 때문에 사용자가 스크립트 또는 명령 줄에서 QMI 프로토콜을 사용할 수있게합니다. 각 스크립트 또는 명령 행 프로그램 실행. QMI를 통해 수행 할 수있는 대부분의 작업의 경우 각 작업에 대해 새 클라이언트를 할당 / 해제하는 것이 가능하지만 Client ID가 유지되어야하는 몇 가지 매우 구체적인 사용 사례가 있습니다 (예 : WDS 네트워크 시작 네트워크) 항상 등록됩니다 (또는 연결이 끊어집니다).

It is worth noting again that avoiding complex operations like these in the kernel driver is by no means a limitation of the driver; instead, the driver is kept as simple as possible and therefore much more robust. A simple driver is also much more flexible, as user-space processes can process all the logic of the protocol, not just parts of it.
커널 드라이버에서 이와 같은 복잡한 작업을 피하는 것이 결코 드라이버의 한계가 아니라는 점을 다시 한번 주목할 필요가 있습니다. 대신 드라이버는 가능한 단순하게 유지되므로 훨씬 강력합니다. 간단한 드라이버는 사용자 공간 프로세스가 프로토콜의 일부분뿐만 아니라 모든 논리를 처리 할 수 ​​있기 때문에 더욱 유연합니다.

It should be obvious by now that while using the one exposed by qmi wwan is a much more complex task. Still, there are already free and open source projects out there that make it equally easy - if not easier - to use the qmi wwan driver.
qmi wwan에 의해 노출 된 것을 사용하는 것이 훨씬 더 복잡한 작업이라는 것을 지금 당연히 알아야합니다. 아직 qmi wwan 드라이버를 사용하는 것이 쉽지는 않겠지만 이미 무료 및 오픈 소스 프로젝트가 있습니다.

This section shows some of the currently available software implementations using the qmi wwan kernel drivers. 이 절에서는 qmi wwan 커널 드라이버를 사용하는 현재 사용 가능한 소프트웨어 구현 중 일부를 보여줍니다.

libqmi is a free and open source library developed by free software contributors, and managed in the freedesktop.org public repositories. libqmi exposes a code source repository with the latest fixes available, which makes it perfect to be able to get the most recent improve-ments and fixes.
libqmi는 무료 소프트웨어 제공자가 개발하고 freedesktop.org 공용 저장소에서 관리되는 무료 오픈 소스 라이브러리입니다. libqmi는 최신 수정 사항을 제공하는 코드 소스 저장소를 제공하므로 가장 최근의 개선 사항 및 수정 사항을 얻을 수 있습니다.

Most Linux-based distributions already include packages for libqmi, and it is also used by ModemManager, a mobile connection manager widely used along with NetworkManager.
대부분의 Linux 기반 배포판에는 이미 libqmi 용 패키지가 포함되어 있으며 NetworkManager와 함께 널리 사용되는 모바일 연결 관리자 인 ModemManager에서도 사용됩니다.

This C library relies on the GLib, GObject and GIO libraries to provide a very high level interface to interact with QMI modems when the qmi wwan kernel driver is being used.
이 C 라이브러리는 GLib, GObject 및 GIO 라이브러리를 사용하여 qmi wwan 커널 드라이버를 사용할 때 QMI 모뎀과 상호 작용할 수있는 매우 높은 수준의 인터페이스를 제공합니다.

A program wanting to use the /dev/cdc-wdmX character device for QMI control will be able to specify that a ’version check’ is to be run during the opening sequence of the device. This check will issue a periodic transmission of a CTL Version Info request until the modem replies with a correct response, so it is equivalent to the one done by the GobiNet driver when it detects a new modem, but triggered in user-space instead of in the kernel. Being optional, the program can decide to fully skip doing it if it knows that the device is already initialized.
QMI 제어를 위해 /dev/cdc-wdmX 문자 장치를 사용하려는 프로그램은 장치의 여는 순서 중에 '버전 확인'을 실행하도록 지정할 수 있습니다. 이 검사는 모뎀이 올바른 응답으로 응답 할 때까지 CTL Version Info 요청을 주기적으로 전송합니다. 따라서 새 모뎀을 발견했지만 GobiNet 드라이버에서 수행 한 것과 동등하지만, 커널 대신에 사용자 공간에서 트리거됩니다. 선택사항인 경우, 프로그램은 장치가 이미 초기화되었다는 것을 알고 있으면 이를 건너 뛸 수 있습니다.

The steps that libqmi will perform while opening the QMI control port are specified in a bitmask of flags, and these also may include configuring the format of network packets to be transferred through the data network interface.
QMI 제어 포트를 여는 동안 libqmi가 수행하는 단계는 플래그의 비트 마스크에 지정되며 데이터 네트워크 인터페이스를 통해 전송할 네트워크 패킷의 형식을 구성하는 것도 포함될 수 있습니다.

Once a QMI control device is open in a program using libqmi, it is then possible to request the allocation and releasing of new QMI clients (and therefore the Client IDs). This is achieved using the CTL Client Allocation and CTL Client Release commands issued by the internal libqmi stack through the open character device. Note that as opposed to the GobiAPI behaviour, libqmi can handle multiple QMI clients for different services over the same open file descriptor.

libqmi can also benefit from the fact that the qmi wwan driver doesn’t automatically release Client IDs when the file descriptor gets closed. A set of flags when requesting to allocate or release a QMI client allow the program to re-use Client IDs that may have been left unreleased previously. The libqmi project offers the following tools:

• qmicli: libqmi comes with a handy command line interface tool which allows sending independent requests to the QMI device, also waiting for the reply of each request. A default run with qmicli will involve allocating and releasing a new QMI client for the service for which the action applies; but there is also the possibility to tell qmicli to re-use a specific Client ID and also to leave the Client ID unreleased when exiting. • qmi-network: libqmi also comes with a bash script which internally uses qmicli. This script can setup a connection to the network using the QMI port from the commandline, and makes sure that the QMI client for the WDS service (the one providing the connection operations) is never released during the connection.

libqmi has an special Proxy flag that may be used when opening a device. If this flag is used, the process will spawn a child process running a ’qmi-proxy’ instance. This proxy process will setup an abstract Linux socket where it will listen to QMI messages from other processes. If all the programs which want to use a QMI port in the system use this same flag when respectively opening the device, they will all end up sharing a single qmi- proxy process which takes care of synchronizing the access to the /dev/cdc-wdmX character device. From another point of view, this qmi-proxy will be the only process really talking to the port.

So, even if the qmi wwan driver doesn’t allow multiple processes to use a single /dev/cdc-wdmX device (as the GobiNet driver does), the multiplexing of different Clients from different processes can still be performed effectively in user-space.

libqmi is general-purpose library making it easier to access the QMI port by other applications. But there are a couple of additional projects that also hold their own user-space implementations to access the port. It should be noted that none of the remaining implementations allow sharing access to the QMI port; i.e. once any of these opens the port to be used, no other application will be able to do so. This is of course a fully valid approach in e.g. embedded systems in which the Gobi modem may be used only for connection purposes.

• oFono: The oFono telephony subsystem implements support for QMI communications with the qmi wwan driver. It doesn’t use any helper library to setup the communication with the modem, and handles the creation and parsing of the QMI messages itself. • uqmi: The uqmi project, maintained by the OpenWRT developers, re-uses the QMI message database implemented in libqmi, but generates code more suitable for embedded devices (e.g. not depending on GLib). Unlike libqmi, though, this project just creates a command line interface program with the most common commands to be run with the modem.

– https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/net/usb/qmi wwan.c

– http://www.freedesktop.org/wiki/Software/libqmi – http://cgit.freedesktop.org/libqmi – http://lists.freedesktop.org/archives/libqmi-devel – http://sigquit.wordpress.com/2012/08/20/an-introduction-to-libqmi – http://sigquit.wordpress.com/2013/09/13/sharing-a-qmi-port-between-processes

libqmi is an on-going effort to get a library providing easy access to Qualcomm’s ‘QMI’ protocol. The current libqmi available is based on the GLib/GObject/GIO-powered ‘libqmi-glib’. libqmi tries to ease the use of the protocol by providing:
libqmi 는 Qualcomm 의 'QMI' 프로토콜에 쉽게 접근하기 위해 개발중인 라이브러리이다. 현재 libqmi 는 GLib/GOjbect/GIO-powered 'libqmi-glib' 에 기반한다. libqmi 는 다음과 같은것을 제공함으로서 프로토콜을 쉽게 사용할수 있도록 하고 있다.

- A ‘QmiDevice‘ object to control the access to the /dev/cdc-wdm device. This object allows creating new per-service ‘QmiClient’s. It also hides the use of the implicit ‘CTL’ service client.
'QmiDevice' 객체로 /dev/cdc-wdm 디바이스를 컨트롤 할수 있다. 이 객체는 서비스별 새로운 'QmiClient' 를 생성한다. 묵시적인 'CTL' 서비스 클라이언트가 보이지 않도록 한다.

- The ‘QmiClient‘ object provides an interface to the set of request/responses of a given service. Users of the library will just need to execute a GIO-asynchronous method to send the request and get the processed response.
'QmiClient' 객체는 연관된 서비스에 요청(request)/응답(response) 을 주고받을 수 있는 인터페이스를 제공한다. 라이브러리 사용자는 GIO-asynchronous 메쏘드를 실행해서 요청을 보내고, 응답을 받아보기만 하면 된다.

- The ‘QmiClient‘ object also provides signals for each of the indications given in the service.

- The input and output arguments needed in requests, responses and indications are compiled into ‘bundles’. These bundles are opaque structs with accessors for their elements, which allow us to add new TLVs to a given message in the future without breaking API/ABI.

The protocol is written in the library as a JSON dictionary of rules, and most of the code to handle the protocol in the library is autogenerated during compilation. If you want to take a look at the currently available interface, check the gtk-doc documentation at: http://www.freedesktop.org/software/libqmi/libqmi-glib/latest/

The libqmi project comes with a command line utility (qmicli) primarily used as a developer tool for testing the libqmi-glib library. Just run the program with ‘–help-all‘ to get all possible actions it can run. A quick example of usage:

$> sudo qmicli -d /dev/cdc-wdm0 --dms-get-manufacturer
[/dev/cdc-wdm0] Device manufacturer retrieved:
Manufacturer: 'Qualcomm Incorporated'

Hint: If you compile the project passing -DMESSAGE_ENABLE_TRACE to CFLAGS, it will dump as DEBUG logs the content and translation of all the QMI messages passed in both directions. You’ll also need ‘–verbose‘ or just ‘-v‘ to show the debug logs when running qmicli.

The project also comes with a small bash script called ‘qmi-network‘, which allows you to launch a broadband connection using libqmi-glib and qmicli. This script requires two arguments; first the cdc-wdm device to talk to, and secondly the action (start|stop|status) to execute. The script can definitely be improved in multiple ways (e.g. send PIN), so if anyone wants to do it patches are very welcome.

The project is currently available in the freedesktop.org infrastructure:

git: http://cgit.freedesktop.org/libqmi

mailing list: http://lists.freedesktop.org/mailman/listinfo/libqmi-devel

bugzilla: https://bugs.freedesktop.org/buglist.cgi?product=libqmi

ModemManager has QMI support through libqmi-glib since release 1.0.

http://sigquit.wordpress.com/2012/08/20/an-introduction-to-libqmi/