<div>Hi!</div><div> </div><div>Sorry, just saw your answer.</div><div> </div><div>Because in my case I just don't have any external host computer.</div><div>The idea is to use modem unit as all-in-one as IoT controller with internet access.</div><div> </div><div>In addition to my previous message (it is still on moderation),</div><div>I modified libqrtr-glib and libqipcrtr4msmipc (keep only changed getsockname func)</div><div>and now seems I can try to send messages, some debug still needed.</div><div> </div><div>Out of the box (original libqrtr-glib and libqipcrtr4msmipc) it doesn't work (at least in mine environment).</div><div> </div><div>Yes, I am using downstream kernel.</div><div>What do you mean:</div><div><div>> The only clean solution would<br />> be to switch to using a mainline kernel, then you would likely not need<br />> any changes in libqmi/MM at all.</div><div>?</div><div> </div><div>Are there some mainline kernel for MDM9x07? Actually I didn't find anything.</div></div><div>I only saw github.com/Biktorgj there are a bit better 3.18 kernel (I built and run it succesfully)</div><div>and 4.14 but the work is not finished (and maybe will be finished).</div><div>28.12.2021, 12:12, "Stephan Gerhold" <<a href="mailto:stephan@gerhold.net" rel="noopener noreferrer">stephan@gerhold.net</a>>:</div><blockquote><p>On Mon, Dec 27, 2021 at 02:10:39PM +0100, Aleksander Morgado wrote:</p><blockquote> > I am still researching EC25 mdm9607 based modem and looking for some way to send qmi command directly via AF_MSM_IPC socket.<br /> ><br /> > Using some code and info from <a href="https://github.com/Biktorgj/meta-qcom/blob/honister/recipes-modem/openqti/files/src/ipc.c" rel="noopener noreferrer">https://github.com/Biktorgj/meta-qcom/blob/honister/recipes-modem/openqti/files/src/ipc.c</a><br /> > I can open AF_MSM_IPC socket and look for avalible services there:<br /> ><br /> > lookup test<br /> > service 1 instance 1 node_id 3 port_id 33 resolve 'Wireless Data Service'<br /> > service 2 instance 1 node_id 3 port_id 47 resolve 'Device Management Service'<br /> > service 3 instance 1 node_id 3 port_id 29 resolve 'Network Access Service'<br /> > service 4 instance 1 node_id 3 port_id 34 resolve 'Quality Of Service service'<br /> > service 5 instance 1 node_id 3 port_id 41 resolve 'Wireless Messaging Service'<br /> > service 7 instance 1 node_id 3 port_id 36 resolve 'Authentication service'<br /> > service 8 instance 1 node_id 3 port_id 37 resolve 'AT service'<br /> > service 11 instance 1 node_id 3 port_id 39 resolve 'User Identity Module service'<br /> > service 12 instance 1 node_id 3 port_id 30 resolve 'Phonebook Management service'<br /> > service 15 instance 1 node_id 3 port_id 4 resolve 'Test service'<br /> > service 17 instance 1 node_id 3 port_id 12 resolve 'Specific absorption rate service'<br /> > service 22 instance 1 node_id 3 port_id 8 resolve 'Time service'<br /> > service 23 instance 1 node_id 3 port_id 7 resolve 'Thermal sensors service'<br /> > service 24 instance 1 node_id 3 port_id 6 resolve 'Thermal mitigation device service'<br /> > service 25 instance 1 node_id 3 port_id 32 resolve 'Service access proxy service'<br /> > service 26 instance 1 node_id 3 port_id 35 resolve 'Wireless data administrative service'<br /> > service 29 instance 1 node_id 3 port_id 38 resolve 'Circuit switched videotelephony service'<br /> > service 34 instance 1 node_id 3 port_id 13 resolve 'Coexistence service'<br /> > service 36 instance 1 node_id 3 port_id 9 resolve 'Persistent device configuration service'<br /> > service 41 instance 257 node_id 3 port_id 10 resolve 'RF radiated performance enhancement service'<br /> > service 42 instance 1 node_id 3 port_id 46 resolve 'Data system determination service'<br /> > service 45 instance 1 node_id 3 port_id 26 resolve 'unknown'<br /> > service 47 instance 1 node_id 3 port_id 31 resolve 'Data Port Mapper service'<br /> > service 48 instance 1 node_id 3 port_id 48 resolve 'unknown'<br /> > service 50 instance 1 node_id 3 port_id 27 resolve 'unknown'<br /> > service 54 instance 1 node_id 3 port_id 11 resolve 'unknown'<br /> > service 55 instance 513 node_id 3 port_id 25 resolve 'unknown'<br /> > service 227 instance 1 node_id 3 port_id 5 resolve 'unknown'<br /> > service 228 instance 1 node_id 3 port_id 14 resolve 'unknown'<br /> ><br /> > I also made several experiments and for example I can send Get Time query to DMS directly via node_id 3 port_id 47<br /> ><br /> > <<<<<< RAW:<br /> > <<<<<< length = 13<br /> > <<<<<< data = 01:0C:00:00:02:01:00:01:00:2F:00:00:00<br /> ><br /> > [01 Jan 1970, 02:52:36] [Debug] [/dev/smdcntl0] Sent generic request (translated)...<br /> > <<<<<< QMUX:<br /> > <<<<<< length = 12<br /> > <<<<<< flags = 0x00<br /> > <<<<<< service = "dms"<br /> > <<<<<< client = 1<br /> > <<<<<< QMI:<br /> > <<<<<< flags = "none"<br /> > <<<<<< transaction = 1<br /> > <<<<<< tlv_length = 0<br /> > <<<<<< message = "Get Time" (0x002F)<br /> ><br /> > But in order to get proper answer I have to delete first 6 bytes (01:0C:00:00:02:01) - QMUX header.<br /> > So seems CID is not handled by the service itself (as qmicli always query CID before any query).<br /> > Here I don't understand the overall conception of QMI routing, CID and other things.<br /> ><br /> > Sending message 7 bytes<br /> > buffer[7]: 00:01:00:2f:00:00:00:<br /> > sendto() 7<br /> > recv() got 47 bytes<br /> > 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:<br /> ><br /> > 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).<br /> > Now think that some proxy app that expose serial port (like socat) and send queries to socket will be ok.<br /> > I didn't manage tune qmuxd to work directly with AF_MSM, only with /dev/smdcntl0 and it not exposed after system startup.<br /> ><br /> > The idea is to send several qmi queries to Data Port Mapper service in order to expose dev/smdcntl0 and rmnet_dataX.<br /> > After I can use qmicli (or even ModemManager) ordinary way and avoid any qualcomm proprietary sw stack.<br /> ><br /> > Maybe somebody can somehow comment on this?<br /> <br /> Isn't all this overlapping with the already upstreamed rpmsg and QRTR<br /> channel support in the Linux kernel? @Stephan Gerhold may be able to<br /> comment here.<br /> </blockquote><p><br />I think they're still working with the downstream/vendor kernel. :(<br />There was some work on a mainline port for MDM9607 but it is not really<br />functional yet I think. :(<br /><br />We use "libqipcrtr4msmipc" as LD_PRELOAD library in postmarketOS which<br />is kind of a wrapper for QRTR (AF_QIPCRTR) to MSM IPC (AF_MSM_IPC):<br /><a href="https://github.com/scintill/libqipcrtr4msmipc/blob/master/main.c" rel="noopener noreferrer">https://github.com/scintill/libqipcrtr4msmipc/blob/master/main.c</a><br /><br />I think it works somewhat for libqmi but to be honest it's a big hack.<br />I never tried using it with ModemManager. The only clean solution would<br />be to switch to using a mainline kernel, then you would likely not need<br />any changes in libqmi/MM at all.<br /><br />Also, why do you want to run MM directly on the modem? It seems easier<br />to just expose the ports via USB as usual and then run MM on the<br />connected device instead (e.g. the PinePhone or some other computer).<br /><br />Thanks,<br />Stephan<br /><br />PS: Nikita, please send your mails as plain text (instead of HTML). :)</p></blockquote><div> </div><div> </div><div>-- </div><div>Nikita Orlov</div><div>Skype: nik_stet</div><div>QQ: 2717846083</div><div> </div>