<div dir="ltr">Thanks a ton Aleksander for your confirmations .. it makes me feel really good !!<br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 15, 2016 at 1:42 PM, Aleksander Morgado <span dir="ltr"><<a href="mailto:aleksander@aleksander.es" target="_blank">aleksander@aleksander.es</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class=""><br> > So, the story so far ::<br> ><br> ><br> > a)<br> > As soon as a QMI-modem is plugged in, the kernel presents the<br> > following two interfaces AUTOMATICALLY ::<br> ><br> > * /dev/cdc-... QMI-port interface<br> > * a wwan-interface<br> ><br> > Kernel takes the help of udev/qcserial/qmi_wwan for the above, and<br> > each of these three modules/drivers are required for proper<br> > functioning of QMI-modem.<br> ><br> > This will happen even if none of user-apps like<br> > NetworkManager/ModemManager/<wbr>mmcli/qmicli are even installed. This is<br> > all the kernel's playground till now.<br> ><br> <br> </span>Yes; except for the qcserial bit; qcserial is only a TTY thing. For a<br> /dev/cdc-wdm port and a wwan interface, you need qmi_wwan and cdc-wdm.<br> <span class=""><br> ><br> > b)<br> > Now, on systems like Ubuntu, NetworkManager and ModemManager start by default.<br> ><br> > If version of libqmi on the system is greater than 1.7, then a<br> > daemon-process "qmi-proxy" will be spawned by ModemManager (since<br> > ModemManager starts automatically on system-boot), and all<br> > QMI-requests/responses will be routed via "qmi-proxy".<br> ><br> ><br> <br> </span>Yes.<br> <span class=""><br> > c)<br> > In user-space, the user may play with the modem via following tools ::<br> ><br> > * mmcli (via mmcli <-> ModemManager <-> qmi-proxy <-><br> > /dev/cdc-.. <-> modem)<br> ><br> > * qmicli (via qmicli <-> qmi-proxy <-> /dev/cdc-.. <-> modem)<br> ><br> > * any custom user-qmi-app (via user-qmi-app <-> qmi-proxy <-><br> > /dev/cdc-.. <-> modem)<br> ><br> ><br> > Important thing to note in this step is that from mmcli / qmcli /<br> > user-qmi-app perspective, each app thinks that the app has exclusive<br> > control of /dev/cdc-.. <-> modem. Obviously, this is being made<br> > possible via concurrent/serialized handing of requests by qmi-proxy.<br> ><br> > Kindly correct me if any of my cumulative understanding is wrong till<br> > this point.<br> ><br> ><br> <br> </span>Yes.<br> <span class=""><br> ><br> > Question 4 :<br> > =========<br> ><br> > Is it 100% safe to mix the usage of qmicli / mmcli (or any any other<br> > custom-user-app for that matter)? This is assuming that none of the<br> > apps will shutdown/reinstantiate /dev/cdc-.. QMI-port.<br> ><br> > For example, can we instantiate a connection via qmicli, and then read<br> > the stored SMSes via mmcli, and then may be run some other command via<br> > qmicli again on the same modem?<br> ><br> > I am assuming that qmicli and mmcli are stateless applications (i.e.<br> > they do not maintain any INTERNAL states for any modem).<br> ><br> > Will be grateful to have a confirmation / rejection on my hypothesis<br> > of question 4.<br> ><br> <br> </span>qmicli is stateless; unless explicitly requested to keep state (i.e.<br> --client-cid=[CID] and --client-no-release-cid). Most of the operations<br> can be run in a stateless mode, where each operation just creates a new<br> client and performs one single operation. If you want to integrate this<br> in a script that periodically runs the same operation over and over,<br> though, you may want to create one single client and re-use the same CID<br> over multiple operations.<br> <br> mmcli is stateless, but ModemManager, the one doing the work, isn't.<br> <br> You're free to mix both, but taking into account that if you modify the<br> state with e.g. qmicli, ModemManager may not be aware of it. e.g. if you<br> set the device in low power with qmicli, ModemManager may still think<br> that it is in full-power mode.<br> <br> If you want to mix both, I'd suggest to keep ModemManager/mmcli for the<br> operations that may modify any kind of state, and qmicli (or some other<br> qmi-proxy based application) for any other read-only operation. E.g. you<br> could run ModemManager to control the modem and the Mobile Radio Monitor<br> (<a href="https://sigquit.wordpress.com/2013/09/17/mobile-radio-monitor" rel="noreferrer" target="_blank">https://sigquit.wordpress.<wbr>com/2013/09/17/mobile-radio-<wbr>monitor</a>) to check<br> the detailed signal/power statistics of the module at the same time.<br> <span class=""><font color="#888888"><br></font></span></blockquote><div><br></div><div>Fortunately, all my requirements could be met by "mmcli" ::<br><br></div><div> * Setting/Instantiating Connection (-m id --create-bearer, -m id --simple-connect)<br></div><div> * Reading SMSes (-m id --messaging-list-sms, -s)<br></div><div> * Getting signal-strength (-m id)<br><br><br></div><div>As soon as I upgraded the ModemManager (as suggested by you in another thread), qmi-proxy came into picture, and all my earlier concerns of concurrency were solved immediately (because of qmi-proxy being the sole door through which ALL qmi-requests are routed to the modem).<br></div><div><br><br></div><div>I do have some minor queries, but they have a highly-local scope.<br>As far as the bigger picture is concerned, things have fitted in perfectly :)<br></div><div><br><br></div><div>Once again, thanks a ton to everyone for the help !!<br><br><br></div><div>Thanks and Regards,<br></div><div>Ajay<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class=""><font color="#888888"> --<br> Aleksander<br> <a href="https://aleksander.es" rel="noreferrer" target="_blank">https://aleksander.es</a><br> </font></span></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Regards,<br>Ajay<br></div> </div></div>