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

[Henrik Ginstmark]

Hi

I have gathered my thoughts in my own version of uqmi.
I think I have dual-stack working.
It's available at https://github.com/mrhaav/openwrt-packages. Feel
free to take a lock and try. :)

/Henrik

Den mån 6 dec. 2021 kl 08:29 skrev Bjørn Mork <bjorn at mork.no>:
>
> 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