Sergey Ryazanov <[email protected]> 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 [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
