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

[Aleksander Morgado]

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

-- 
Aleksander
https://aleksander.es