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

[Sergey Ryazanov]

On Sun, Dec 5, 2021 at 5:12 PM Bjørn Mork <bjorn at mork.no> wrote:
> Sergey Ryazanov <ryazanov.s.a at gmail.com> writes:
>> On Sun, Dec 5, 2021 at 3:32 PM Bjørn Mork <bjorn at mork.no> wrote:
>>> Sergey Ryazanov <ryazanov.s.a at gmail.com> writes:
>>>> I am, as an occasional user of an LTE modem, never faced a case when
>>>> the modem is unable to register with a network due to an unconfigured
>>>> APN. The most prominent fact is that no one else ever faced such case
>>>> for a 7 years of the uqmi existence. It looks like you either ran into
>>>> a very special operator, or you have a buggy modem that is recovered
>>>> via the airplane mode. It is also possible that I do not fully
>>>> understand your case.
>>>
>>> I agree that this is rare.  But I'm pretty sure it can happen.
>>>
>>> A more common case is that the modem picks some arbitrary previously
>>> used APN, e.g. profile #1. This will often be fine. But it can be really
>>> annoying when it isn't. For example becasue that profile was configured
>>> as IPv4 only and you want a dual-stack connection.
>>
>> Should not a modem reestablish a bearer as soon as a user provides a
>> new APN along with the connect QMI command?
>
> I don't know what a modem should do.  I only know what I've observed: If
> a modem is attached to a network using an IPv4 only default bearer, then
> you cannot connect a dual stack bearer.  You can connect it, but you'll
> only get the IPv4 part of the session up.  And connecting an IPv6 only
> APN is impossible in this case.

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.

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.

>>> So flight mode will sometimes be necessary when changing APN.
>>
>> Just to make it clear. Should switching to the airplane mode be a part
>> of connection establishing procedure (i.e. qmi.sh script)? Or would it
>> be enough to have the mode switching command in the uqmi utility? So a
>> user will be able to manually toggle the airplane mode during the APN
>> reconfiguration.
>
> I'm not able to agree with myself here :-)
>
> On one hand, I believe toggling airplane mode after we know the initial
> APN would make this more robust.  On the other hand, I fear that kind of
> automatic stuff.
>
> Better leave if for the user as a manual toggle, I guess.

You just spelled out all my thoughts :) I am also afraid that such
automation will break a lot of modems, since I am not sure how many
modem models will reliably exit the airplane mode. And how many models
would require workarounds like power circle, etc.

>>> Just don't ever force it. We don't want to lose the ability to connect
>>> to more than one APN (although this probably isn't supported in uqmi yet
>>> since you can't setup QMAP).
>>
>> Do not understand this phrase. How can the airplane mode break a
>> multi-bearer setup?
>
> I don't know if this was the plan or not.  But I feared that someone got
> the idea that you could force airplane mode whenever a new APN is
> configured.  This would obviously break existing connections.

Oh, now I got it. Thank you for your clarification.

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

-- 
Sergey