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

[Henrik Ginstmark]

Hi

My intention was to speed up the registration to the LTE network.
When the LTE terminal is powered on it will attach with the modem
default APN profile. If that is empty, then the network will assign the
network default APN and you get an IP address.

But if the modem default APN is incorrect, or if your operator does not
assign a default APN, you will be rejected in LTE and the modem will,
after a while, register to 3G, since you don´t need a valid APN to
register to 3G.

But if we verify that the modem default APN is correct, before we do the
registration, we will be sure that the registration goes smoothly.
The modem will store the default APN setting.


My proposal to qmi.sh, roughly.

Check PIN
Check data format 802.3/raw-ip
Check modem default APN settings
If the default APN setting are incorrect,
  Airplane mode on
  Change default APN settings
  Airplane mode off
Check operator and radio technology
run --start-network with client_id wds

I don´t think this will break anything and you can still have
the possibility of adding a secondary APN.


/Henrik

Den sön 5 dec. 2021 kl 16:12 skrev Sergey Ryazanov <ryazanov.s.a at gmail.com>:
>
> 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