On Sun, Dec 5, 2021 at 5:12 PM Bjørn Mork <[email protected]> wrote: > Sergey Ryazanov <[email protected]> writes: >> On Sun, Dec 5, 2021 at 3:32 PM Bjørn Mork <[email protected]> wrote: >>> Sergey Ryazanov <[email protected]> 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 _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
