qmicli quering AF_MSM_IPC socket directly

Stephan Gerhold stephan at gerhold.net
Tue Dec 28 09:11:50 UTC 2021


On Mon, Dec 27, 2021 at 02:10:39PM +0100, Aleksander Morgado wrote:
> > I am still researching EC25 mdm9607 based modem and looking for some way to send qmi command directly via AF_MSM_IPC socket.
> >
> > Using some code and info from https://github.com/Biktorgj/meta-qcom/blob/honister/recipes-modem/openqti/files/src/ipc.c
> > I can open AF_MSM_IPC socket and look for avalible services there:
> >
> > lookup test
> > service 1 instance 1 node_id 3 port_id 33 resolve 'Wireless Data Service'
> > service 2 instance 1 node_id 3 port_id 47 resolve 'Device Management Service'
> > service 3 instance 1 node_id 3 port_id 29 resolve 'Network Access Service'
> > service 4 instance 1 node_id 3 port_id 34 resolve 'Quality Of Service service'
> > service 5 instance 1 node_id 3 port_id 41 resolve 'Wireless Messaging Service'
> > service 7 instance 1 node_id 3 port_id 36 resolve 'Authentication service'
> > service 8 instance 1 node_id 3 port_id 37 resolve 'AT service'
> > service 11 instance 1 node_id 3 port_id 39 resolve 'User Identity Module service'
> > service 12 instance 1 node_id 3 port_id 30 resolve 'Phonebook Management service'
> > service 15 instance 1 node_id 3 port_id 4 resolve 'Test service'
> > service 17 instance 1 node_id 3 port_id 12 resolve 'Specific absorption rate service'
> > service 22 instance 1 node_id 3 port_id 8 resolve 'Time service'
> > service 23 instance 1 node_id 3 port_id 7 resolve 'Thermal sensors service'
> > service 24 instance 1 node_id 3 port_id 6 resolve 'Thermal mitigation device service'
> > service 25 instance 1 node_id 3 port_id 32 resolve 'Service access proxy service'
> > service 26 instance 1 node_id 3 port_id 35 resolve 'Wireless data administrative service'
> > service 29 instance 1 node_id 3 port_id 38 resolve 'Circuit switched videotelephony service'
> > service 34 instance 1 node_id 3 port_id 13 resolve 'Coexistence service'
> > service 36 instance 1 node_id 3 port_id 9 resolve 'Persistent device configuration service'
> > service 41 instance 257 node_id 3 port_id 10 resolve 'RF radiated performance enhancement service'
> > service 42 instance 1 node_id 3 port_id 46 resolve 'Data system determination service'
> > service 45 instance 1 node_id 3 port_id 26 resolve 'unknown'
> > service 47 instance 1 node_id 3 port_id 31 resolve 'Data Port Mapper service'
> > service 48 instance 1 node_id 3 port_id 48 resolve 'unknown'
> > service 50 instance 1 node_id 3 port_id 27 resolve 'unknown'
> > service 54 instance 1 node_id 3 port_id 11 resolve 'unknown'
> > service 55 instance 513 node_id 3 port_id 25 resolve 'unknown'
> > service 227 instance 1 node_id 3 port_id 5 resolve 'unknown'
> > service 228 instance 1 node_id 3 port_id 14 resolve 'unknown'
> >
> > I also made several experiments and for example I can send Get Time query to DMS directly via node_id 3 port_id 47
> >
> > <<<<<< RAW:
> > <<<<<<   length = 13
> > <<<<<<   data   = 01:0C:00:00:02:01:00:01:00:2F:00:00:00
> >
> > [01 Jan 1970, 02:52:36] [Debug] [/dev/smdcntl0] Sent generic request (translated)...
> > <<<<<< QMUX:
> > <<<<<<   length  = 12
> > <<<<<<   flags   = 0x00
> > <<<<<<   service = "dms"
> > <<<<<<   client  = 1
> > <<<<<< QMI:
> > <<<<<<   flags       = "none"
> > <<<<<<   transaction = 1
> > <<<<<<   tlv_length  = 0
> > <<<<<<   message     = "Get Time" (0x002F)
> >
> > But in order to get proper answer I have to delete first 6 bytes (01:0C:00:00:02:01) - QMUX header.
> > So seems CID is not handled by the service itself (as qmicli always query CID before any query).
> > Here I don't understand the overall conception of QMI routing, CID and other things.
> >
> > Sending message 7 bytes
> > buffer[7]: 00:01:00:2f:00:00:00:
> > sendto() 7
> > recv() got 47 bytes
> > buffer[47]: 02:01:00:2f:00:28:00:02:04:00:00:00:00:00:01:08:00:2d:a4:db:b8:f6:00:00:00:10:08:00:39:8d:12:67:34:01:00:00:11:08:00:6c:14:9e:00:00:00:00:00:
> >
> > First I thought to add some feature to libqmi in order to send qmi directly via AF_MSM, but now it seems too complicated (moreover I am not familiar with libglib2).
> > Now think that some proxy app that expose serial port (like socat) and send queries to socket will be ok.
> > I didn't manage tune qmuxd to work directly with AF_MSM, only with /dev/smdcntl0 and it not exposed after system startup.
> >
> > The idea is to send several qmi queries to Data Port Mapper service in order to expose dev/smdcntl0 and rmnet_dataX.
> > After I can use qmicli (or even ModemManager) ordinary way and avoid any qualcomm proprietary sw stack.
> >
> > Maybe somebody can somehow comment on this?
> 
> Isn't all this overlapping with the already upstreamed rpmsg and QRTR
> channel support in the Linux kernel? @Stephan Gerhold may be able to
> comment here.
> 

I think they're still working with the downstream/vendor kernel. :(
There was some work on a mainline port for MDM9607 but it is not really
functional yet I think. :(

We use "libqipcrtr4msmipc" as LD_PRELOAD library in postmarketOS which
is kind of a wrapper for QRTR (AF_QIPCRTR) to MSM IPC (AF_MSM_IPC):
https://github.com/scintill/libqipcrtr4msmipc/blob/master/main.c

I think it works somewhat for libqmi but to be honest it's a big hack.
I never tried using it with ModemManager. The only clean solution would
be to switch to using a mainline kernel, then you would likely not need
any changes in libqmi/MM at all.

Also, why do you want to run MM directly on the modem? It seems easier
to just expose the ports via USB as usual and then run MM on the
connected device instead (e.g. the PinePhone or some other computer).

Thanks,
Stephan

PS: Nikita, please send your mails as plain text (instead of HTML). :)


More information about the libqmi-devel mailing list