qmicli quering AF_MSM_IPC socket directly

[Aleksander Morgado]

Hey Nikita,

>
> 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.

-- 
Aleksander
https://aleksander.es