[uqmi] dms: add --get-operating-mode

[Bjørn Mork]

Sergey Ryazanov <ryazanov.s.a at gmail.com> writes:

> Can you reveal what modem model has such nasty behaviour? I personally
> test IPv6 with Huawei E3372 (NCM, not QMI) and Sierra MC7304, both of
> them work stable. But I can not recall whether they established the
> IPv6 connection as soon as a PDP context was reconfigured or I needed
> to reattach (power circle) them. Need to recheck someday.

I believe this is a common issue, not limited to a specific vendor.  The
last modem where I noticed it was a Quectel RG502Q-EA.  But I'm pretty
sure the problem was there in older modems too.  You should be able to
see it in the MC7304.  Don't you?  Not sure about the non-Qualcomm
modems.

> And do you remember whether the airplane mode was the only option to
> configure a new APN or some other operation also help to recover IPv6
> connectivity? E.g. disconnect/connect QMI command or a modem power
> circle.

I haven't tried ariplane mode to resolve this.  But that should work
since it will cause the modem to reattach to the network..

Since this is mostly a one-time thing I've just changed the modem config
and rebooted the modem.  Usually after debugging for a while before I
remember to check the default APN config.
>>> BTW, when you are talking about QMAP, did you mean utilizing the QMAP
>>> demux module from the kernel as it is or implementing the WWAN
>>> subsystem ops for the qmi_wwan module. In other words, did you mean
>>> protocol or implementation?
>>
>> I was talking about the (lack of) muxing setup support in uqmi.  There
>> is no way to tell the modem firmware how the different channels are
>> supposed to be connected.
>
> Ouch, now I got this too. Whether the --profile <index> option serves
> this purpose, or do we need to implement some other message?
>
> I know this goes beyond the APN change discussion, but since such a
> case presented itself, I want to ask you a question. What do you think
> about turning the current linux QMAP implementation into a library and
> use it within the qmi_wwan driver to implement the data channels
> demuxing that is controlled via the WWAN ops?
>
> I would like to try this, but I have been pointed out a couple of
> times about the complexity of the Qualcomm protocols, so I am just
> afraid to propose such a change :)

I'm not sure I understand what you want to do.  Muxing is sort-of
supported in qmi_wwan. But the proper solution is to use the rmnet
driver on top of it. The legacy implementation in qmi_wwan doesn't
support QMAPv5, and probably won't since I don't think we can add that
without more userspace knobs.  And I promised the last change to the
userspace ABI was ... well,... the LAST one.

As for the PCIe stuff and all that, I assume Qualcomm will support that
using the rmnet driver on top of the PCIe transport drivers.  If they
continue to support QMAP/QMI/RMNET it at all?  The last I heard, they
wanted to go all-in for MBIM.  Which makes muxing so much easier.

Wrt useerspace, there is QMAP support in libqmi. Having similar i uqmi
might be nice, but it's probably not the feature most people are
missing.


Bjørn