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 <bj...@mork.no>: > > Sergey Ryazanov <ryazanov....@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 _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
