running libqmi on Android / qmuxd

[Reinhard Speyerer]

On Mon, Dec 19, 2016 at 11:09:49AM +0100, Aleksander Morgado wrote:
> Hey hey Harald,
> 
> On Sun, Dec 18, 2016 at 10:58 AM, Harald Welte <laforge at gnumonks.org> wrote:
> > I know how to access qmuxd and have soem early proof-of-concept code to
> > e.g. obtain the IMEI via it.
> >
> > So what I'm asking for is an idea where it is best to split libqmi and
> > create a Frankenstein-backend that talks to qmuxd, rather than to a
> > /dev/cdc-wdm device
> >
> > The goal is to have the 'upper layer' from libqmi, together with some
> > free softwre glue code to talk to qmuxd, and thus be free of linking or
> > includign any proprietary qualcomm bits.
> 
> All the logic managing the client allocation/deallocation and all that
> is done by the GobiNet driver in the kernel (when using Qualcomm's
> driver) or by our libqmi in userspace (when using qmi_wwan), using the
> QMI CTL Service. When using libqmi, the whole logic of the "CTL
> service" is hidden within the QmiDevice implementation. A user of the
> API has methods to "allocate a client" or "release a client"; how that
> is done is totally hidden. This is a key point, because that allows us
> to not just talk to the /dev/cdc-wdm device to issue QMI CTL commands;
> it also would allow us to allocate and release client ids in whatever
> way we need (e.g. we could do ioctl()s on the /dev/qcqmiX exposed by
> GobiNet, or talk to qmuxd).
> 
> I don't know much about how the qmuxd operation goes on, but if you
> already have working code doing QMI DMS operations it shouldn't be
> very hard to implement a QmiDevice subclass that uses the qmuxd
> backend, or just extend the QmiDevice we have with some additional
> logic, like we did for the qmi-proxy operation (where the QmiDevice
> talks to a daemon listening in a UNIX socket, instead of directly to a
> /dev/cdc-wdm device).

Hi Aleksander and Harald,

as can be seen from Core/Socket.h of the Gobi Extensible API the
QMUXD protocol uses these messages types

enum eQMUXDMessageTypes
{
   eQMUXD_MSG_WRITE_QMI_SDU = 0,
   eQMUXD_MSG_ALLOC_QMI_CLIENT_ID = 1,
   eQMUXD_MSG_RELEASE_QMI_CLIENT_ID = 2,
};

so the mapping should be pretty simple.

At least on one MDM-based Linux embedded systems I tried qmuxd still works
out of the box with an application which uses the Gobi Extensible API:

/ # uname -a
Linux mdm9625 3.4.0+ #1 PREEMPT Wed Nov 12 10:48:03 CST 2014 armv7l GNU/Linux
/ # /tmp/gobicmapicli -g /tmp/GobiConnectionMgmt.so SOCKET:/var/,0 1 2 3
+OK gobicmapicli 2.18 connected to SOCKET:/var/,0, QMI service(s) 1,2,3
DMSGetSoftwareVersion 3000
+OK 020400000000000127004d5053532e44492e322e302e312e63312d30303032352d4d393632354c414141414e415a4d2d31
quit
+OK Bye

One feature that seems to missing from both the GobiNet driver and the
QMUXD protocol is an equivalent to QMI_CTL_GET_VERSION_INFO however.

Regards,
Reinhard