Basic (Idiotic) questions about ModemManager / mmcli / libqmi / modems / life

[Ajay Garg]

Thanks a ton Aleksander for your confirmations .. it makes me feel really
good !!

On Mon, Aug 15, 2016 at 1:42 PM, Aleksander Morgado <
aleksander at aleksander.es> wrote:

>
> > So, the story so far ::
> >
> >
> > a)
> > As soon as a QMI-modem is plugged in, the kernel presents the
> > following two interfaces AUTOMATICALLY ::
> >
> >          * /dev/cdc-... QMI-port interface
> >          * a wwan-interface
> >
> > Kernel takes the help of udev/qcserial/qmi_wwan for the above, and
> > each of these three modules/drivers are required  for proper
> > functioning of QMI-modem.
> >
> > This will happen even if none of user-apps like
> > NetworkManager/ModemManager/mmcli/qmicli are even installed. This is
> > all the kernel's playground till now.
> >
>
> Yes; except for the qcserial bit; qcserial is only a TTY thing. For a
> /dev/cdc-wdm port and a wwan interface, you need qmi_wwan and cdc-wdm.
>
> >
> > b)
> > Now, on systems like Ubuntu, NetworkManager and ModemManager start by
> default.
> >
> > If version of libqmi on the system is greater than 1.7, then a
> > daemon-process "qmi-proxy" will be spawned by ModemManager (since
> > ModemManager starts automatically on system-boot), and all
> > QMI-requests/responses will be routed via "qmi-proxy".
> >
> >
>
> Yes.
>
> > c)
> > In user-space, the user may play with the modem via following tools ::
> >
> >          * mmcli (via mmcli <-> ModemManager <-> qmi-proxy <->
> > /dev/cdc-.. <-> modem)
> >
> >          * qmicli (via qmicli <-> qmi-proxy <-> /dev/cdc-.. <-> modem)
> >
> >          * any custom user-qmi-app (via user-qmi-app <-> qmi-proxy <->
> > /dev/cdc-.. <-> modem)
> >
> >
> > Important thing to note in this step is that from mmcli / qmcli /
> > user-qmi-app perspective, each app thinks that the app has exclusive
> > control of /dev/cdc-.. <-> modem. Obviously, this is being made
> > possible via concurrent/serialized handing of requests by qmi-proxy.
> >
> > Kindly correct me if any of my cumulative understanding is wrong till
> > this point.
> >
> >
>
> Yes.
>
> >
> > Question 4 :
> > =========
> >
> > Is it 100% safe to mix the usage of qmicli / mmcli (or any any other
> > custom-user-app for that matter)? This is assuming that none of the
> > apps will shutdown/reinstantiate /dev/cdc-.. QMI-port.
> >
> > For example, can we instantiate a connection via qmicli, and then read
> > the stored SMSes via mmcli, and then may be run some other command via
> > qmicli again on the same modem?
> >
> > I am assuming that qmicli and mmcli are stateless applications (i.e.
> > they do not maintain any INTERNAL states for any modem).
> >
> > Will be grateful to have a confirmation / rejection on my hypothesis
> > of question 4.
> >
>
> qmicli is stateless; unless explicitly requested to keep state (i.e.
> --client-cid=[CID] and --client-no-release-cid). Most of the operations
> can be run in a stateless mode, where each operation just creates a new
> client and performs one single operation. If you want to integrate this
> in a script that periodically runs the same operation over and over,
> though, you may want to create one single client and re-use the same CID
> over multiple operations.
>
> mmcli is stateless, but ModemManager, the one doing the work, isn't.
>
> You're free to mix both, but taking into account that if you modify the
> state with e.g. qmicli, ModemManager may not be aware of it. e.g. if you
> set the device in low power with qmicli, ModemManager may still think
> that it is in full-power mode.
>
> If you want to mix both, I'd suggest to keep ModemManager/mmcli for the
> operations that may modify any kind of state, and qmicli (or some other
> qmi-proxy based application) for any other read-only operation. E.g. you
> could run ModemManager to control the modem and the Mobile Radio Monitor
> (https://sigquit.wordpress.com/2013/09/17/mobile-radio-monitor) to check
> the detailed signal/power statistics of the module at the same time.
>
>
Fortunately, all my requirements could be met by "mmcli" ::

         * Setting/Instantiating Connection (-m id --create-bearer, -m id
--simple-connect)
         * Reading SMSes (-m id --messaging-list-sms, -s)
         * Getting signal-strength (-m id)


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


I do have some minor queries, but they have a highly-local scope.
As far as the bigger picture is concerned, things have fitted in perfectly
:)


Once again, thanks a ton to everyone for the help !!


Thanks and Regards,
Ajay


> --
> Aleksander
> https://aleksander.es
>



-- 
Regards,
Ajay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/modemmanager-devel/attachments/20160815/f622a2dc/attachment.html>