Re: [uqmi] dms: add --get-operating-mode
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 : > > Sergey Ryazanov 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 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
Re: [uqmi] dms: add --get-operating-mode
Sergey Ryazanov 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 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
Re: [uqmi] dms: add --get-operating-mode
On Sun, Dec 5, 2021 at 9:57 PM Henrik Ginstmark wrote: > I'm working for a cellular operator and I have the possibilities to monitor > the > registration of the modem from the network side. The registration of an LTE > terminal is clearly described in the 3GPP specifications and I don´t agree > with > the options you mention. An LTE terminal can not register with an invalid APN. Yep. I rechecked the 3GPP TS 23.401 and found that the network may allow APN-less registration for IoT devices, regular modems do not fall into this category. Oops. I should recall these IoT specific stuff earlier. And I am sorry for my mistake. The only thing left to do is to deal with the network responsibility for the default APN (P-GW) providing. The same specification said that a network *should* use a default APN if a registering UE (modem) does not provide any. As someone familiar with the operator business, could you please estimate how many operators do not utilize the default APN feature? > I have created commands for profile modification. But they are not polished ;) > --get-profile-settings : Get APN profile settings (3gpp, 3gpp2),#\n" > \ > --get-default-profile-number : Get default profile number (3gpp, > 3gpp2)\n" \ > --modify-profile ,# Modify profile number (3gpp, 3gpp2)\n" \ > --apn :Use APN\n" \ > --pdp-type ipv4|ipv6|ipv4v6>: Use pdp-type for the connection\n" \ > --username : Use network username\n" \ > --password : Use network password\n" \ > --auth-type pap|chap|both|none: Use network authentication type\n" \ > > > But, if you don't see any benefit with my proposal I´m fine. I should say sorry if my stream of questions looks like an objection against your proposal. The described situation with the inability to register without a preconfigured APN just looks so strange that I can not resist a wish to investigate it :) Moreover, as an occasional LTE modem user, I will be the man who benefits from your work once it is integrated into the uqmi utility. The only thing that worries me is, should we do the default APN reconfiguration (via the airplane mode toggling) automatically in qmi.sh, or should we only provide an ability without forcing it? I am afraid that while trying to automatically solve one rare issue, we unintentionally break a lot of running setups by triggering a modem bug in the airplane mode exiting procedure. Anyway, I am just an occasional project contributor, not from the core developers staff, so you can ignore my thoughts all together ;) > Den sön 5 dec. 2021 kl 18:56 skrev Sergey Ryazanov : >> On Sun, Dec 5, 2021 at 7:43 PM Henrik Ginstmark wrote: >>> My intention was to speed up the registration to the LTE network. >> >> If we talk about a modem that is part of a router, then I doubt >> whether the airplane mode activation will be able to speed up the >> registration procedure. After a router power on, the main router >> firmware should complete its own boot process before it will be able >> to switch the modem into airplane mode. But the modem will be powered >> in the same time as the router CPU and most probably the modem will >> boot faster. So when the main firmware becomes ready, the modem will >> be already registered with a network. And triggering the airplane mode >> will only delay data communication readiness. >> >> It would be nice to have the mode configuration command in the uqmi >> utility. But toggling the airplane mode in an automatic fashion can be >> even dangerous (see below). >> >>> 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. >> >> Please be more specific, what modem model and operator do we talk >> about? As I showed earlier, a modem has a lot of options during >> network registration, and earlier community experience suggests that >> it is most probable that a modem will register with a network smoothly >> even without an earlier preconfigured APN. So we should make our >> discussion more specific. >> >>> 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. >> >> When you talking about the default APN did you mean the first >> connection profile? There are only two commands that carry APN: >> profile creation and network start. Network start should be called >> after the network registration completion, while the profile >> configuration command is not yet implemented. >> >>> My proposal to qmi.sh, roughly. >>> >>> Check PIN >>> Check data format 802.3/raw-ip >>> Check
Re: [uqmi] dms: add --get-operating-mode
Hi I'm working for a cellular operator and I have the possibilities to monitor the registration of the modem from the network side. The registration of an LTE terminal is clearly described in the 3GPP specifications and I don´t agree with the options you mention. An LTE terminal can not register with an invalid APN. I have created commands for profile modification. But they are not polished ;) --get-profile-settings : Get APN profile settings (3gpp, 3gpp2),#\n" \ --get-default-profile-number : Get default profile number (3gpp, 3gpp2)\n" \ --modify-profile ,# Modify profile number (3gpp, 3gpp2)\n" \ --apn :Use APN\n" \ --pdp-type ipv4|ipv6|ipv4v6>: Use pdp-type for the connection\n" \ --username : Use network username\n" \ --password : Use network password\n" \ --auth-type pap|chap|both|none: Use network authentication type\n" \ But, if you don't see any benefit with my proposal I´m fine. /Henrik Den sön 5 dec. 2021 kl 18:56 skrev Sergey Ryazanov : > > On Sun, Dec 5, 2021 at 7:43 PM Henrik Ginstmark wrote: > > My intention was to speed up the registration to the LTE network. > > If we talk about a modem that is part of a router, then I doubt > whether the airplane mode activation will be able to speed up the > registration procedure. After a router power on, the main router > firmware should complete its own boot process before it will be able > to switch the modem into airplane mode. But the modem will be powered > in the same time as the router CPU and most probably the modem will > boot faster. So when the main firmware becomes ready, the modem will > be already registered with a network. And triggering the airplane mode > will only delay data communication readiness. > > It would be nice to have the mode configuration command in the uqmi > utility. But toggling the airplane mode in an automatic fashion can be > even dangerous (see below). > > > 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. > > Please be more specific, what modem model and operator do we talk > about? As I showed earlier, a modem has a lot of options during > network registration, and earlier community experience suggests that > it is most probable that a modem will register with a network smoothly > even without an earlier preconfigured APN. So we should make our > discussion more specific. > > > 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. > > When you talking about the default APN did you mean the first > connection profile? There are only two commands that carry APN: > profile creation and network start. Network start should be called > after the network registration completion, while the profile > configuration command is not yet implemented. > > > 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 > > This is my primary concern. How many modem models will reliably exit > the airplane mode without any issues? > > > 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. > > -- > Sergey ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [uqmi] dms: add --get-operating-mode
On Sun, Dec 5, 2021 at 7:43 PM Henrik Ginstmark wrote: > My intention was to speed up the registration to the LTE network. If we talk about a modem that is part of a router, then I doubt whether the airplane mode activation will be able to speed up the registration procedure. After a router power on, the main router firmware should complete its own boot process before it will be able to switch the modem into airplane mode. But the modem will be powered in the same time as the router CPU and most probably the modem will boot faster. So when the main firmware becomes ready, the modem will be already registered with a network. And triggering the airplane mode will only delay data communication readiness. It would be nice to have the mode configuration command in the uqmi utility. But toggling the airplane mode in an automatic fashion can be even dangerous (see below). > 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. Please be more specific, what modem model and operator do we talk about? As I showed earlier, a modem has a lot of options during network registration, and earlier community experience suggests that it is most probable that a modem will register with a network smoothly even without an earlier preconfigured APN. So we should make our discussion more specific. > 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. When you talking about the default APN did you mean the first connection profile? There are only two commands that carry APN: profile creation and network start. Network start should be called after the network registration completion, while the profile configuration command is not yet implemented. > 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 This is my primary concern. How many modem models will reliably exit the airplane mode without any issues? > 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. -- Sergey ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [uqmi] dms: add --get-operating-mode
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 : > > On Sun, Dec 5, 2021 at 5:12 PM Bjørn Mork wrote: > > Sergey Ryazanov writes: > >> On Sun, Dec 5, 2021 at 3:32 PM Bjørn Mork wrote: > >>> Sergey Ryazanov 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 talkin
Re: [uqmi] dms: add --get-operating-mode
On Sun, Dec 5, 2021 at 5:12 PM Bjørn Mork wrote: > Sergey Ryazanov writes: >> On Sun, Dec 5, 2021 at 3:32 PM Bjørn Mork wrote: >>> Sergey Ryazanov 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 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 openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [uqmi] dms: add --get-operating-mode
Sergey Ryazanov writes: > On Sun, Dec 5, 2021 at 3:32 PM Bjørn Mork wrote: >> Sergey Ryazanov 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. >> 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. >> 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. > 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. Bjørn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [uqmi] dms: add --get-operating-mode
On Sun, Dec 5, 2021 at 3:32 PM Bjørn Mork wrote: > Sergey Ryazanov 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? > 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. > 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? 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? -- Sergey ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [uqmi] dms: add --get-operating-mode
Sergey Ryazanov 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. So flight mode will sometimes be necessary when changing APN. 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). Bjørn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [uqmi] dms: add --get-operating-mode
CC Piotr and Matti to draw some more attention to this case. On Sun, Dec 5, 2021 at 2:19 AM Henrik Ginstmark wrote: > Den lör 4 dec. 2021 kl 23:19 skrev Sergey Ryazanov : >> On Sat, Dec 4, 2021 at 6:22 PM Henrik Ginstmark wrote: >>> This command make it possible to query if the modem is in flight mode or >>> not. >>> >>> If you need to change your APN setting it should be done during flight mode >>> on. >> >> Just curious, is this true for any Qualcomm based mode or only for a >> specific model? > > When an LTE terminal is powered on it needs a valid APN to be able to > register to the > network. Some cellular operators allow an "empty" APN and then set a default > APN > to the terminal. > The most optimal way to power on an LTE terminal would be with flight mode on, > check that the correct APN is configured and then set flight mode off. > This is for all LTE terminals. Sounds stranger. In the OpenWrt at the moment, APN passed to a modem during the data connection establishment stage. A long time after the modem will be registered with a cell network. uqmi.sh script even has a special busy loop that waits the modem registration procedure completion to avoid data connection establishing failure. From the 3GPP specification point of view, a UE (modem) has at least three options during the initial network registration procedure: * request the immediate default connection establishing with a specific P-GW (APN) via a long and tricky procedure; * request the immediate default connection establishing without an explicit APN, then MME should use a default one P-GW (APN); * do not establish a data connection immediately. 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 am not against this patch, I am just curious about the described situation with a strict APN requirement. > I have a local uqmi version with commands for checking and modifying > the APN settings. > >>> To make it possible to automate change of APN setting --get-operating-mode >>> is >>> needed. >>> >>> Signed-off-by: Henrik Ginstmark -- Sergey ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [uqmi] dms: add --get-operating-mode
Please find a few comments related to a patch submission below. As for the airplane mode requirements, I would like to split that discussion into a separate thread and will send a separate reply. On Sun, Dec 5, 2021 at 2:19 AM Henrik Ginstmark wrote: > Den lör 4 dec. 2021 kl 23:19 skrev Sergey Ryazanov : >> On Sat, Dec 4, 2021 at 6:22 PM Henrik Ginstmark wrote: >>> This command make it possible to query if the modem is in flight mode or >>> not. >>> >>> If you need to change your APN setting it should be done during flight mode >>> on. >> >> Just curious, is this true for any Qualcomm based mode or only for a >> specific model? > > When an LTE terminal is powered on it needs a valid APN to be able to > register to the > network. Some cellular operators allow an "empty" APN and then set a default > APN > to the terminal. > The most optimal way to power on an LTE terminal would be with flight mode on, > check that the correct APN is configured and then set flight mode off. > This is for all LTE terminals. > > I have a local uqmi version with commands for checking and modifying > the APN settings. > >> >>> To make it possible to automate change of APN setting --get-operating-mode >>> is >>> needed. >>> >>> Signed-off-by: Henrik Ginstmark >> >> Your patch seems broken. Consider using git-format-patch and >> git-send-email to prepare and submit the patch, please. > > Sorry, I´m new to this. Do you know where I can find information about > git-format-patch and git-send-email? You can find more details about these utilities in the corresponding man pages. Please see man git-format-patch and man git-send-email You can find some more information about the patches submitting procedure in the project wiki: * https://openwrt.org/submitting-patches * https://openwrt.org/docs/guide-developer/working-with-git-email Also a good overview of the patch submitting can be found in the Linux kernel documentation: * https://www.kernel.org/doc/html/latest/process/submitting-patches.html A typical workflow for a uqmi patch submission will looks like this: $ git clone https://git.openwrt.org/project/uqmi.git $ cd uqmi $ git checkout -b new-feature-branch hack the code to introduce a new functionality with your favorite code editor $ git commit -s $ git format-patch HEAD^ $ git send-email --to=... --cc=... foo_bar.patch > What I understand is uqmi a sub-project > to openwrt, or? Yep. uqmi is the OpenWrt sub-project. > I´m still learning C. I will try to optimize the code in a better way. Your code looks well. Just needs some polishing :) -- Sergey ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [uqmi] dms: add --get-operating-mode
Hi Sergey
Den lör 4 dec. 2021 kl 23:19 skrev Sergey Ryazanov :
>
> Hello Henrik,
>
> On Sat, Dec 4, 2021 at 6:22 PM Henrik Ginstmark wrote:
> > This command make it possible to query if the modem is in flight mode or
> > not.
> >
> > If you need to change your APN setting it should be done during flight mode
> > on.
>
> Just curious, is this true for any Qualcomm based mode or only for a
> specific model?
When an LTE terminal is powered on it needs a valid APN to be able to
register to the
network. Some cellular operators allow an "empty" APN and then set a default APN
to the terminal.
The most optimal way to power on an LTE terminal would be with flight mode on,
check that the correct APN is configured and then set flight mode off.
This is for all LTE terminals.
I have a local uqmi version with commands for checking and modifying
the APN settings.
>
> > To make it possible to automate change of APN setting --get-operating-mode
> > is
> > needed.
> >
> > Signed-off-by: Henrik Ginstmark
>
> Your patch seems broken. Consider using git-format-patch and
> git-send-email to prepare and submit the patch, please.
Sorry, I´m new to this. Do you know where I can find information about
git-format-patch and git-send-email? What I understand is uqmi a sub-project
to openwrt, or?
I´m still learning C. I will try to optimize the code in a better way.
>
> BTW, it is a good idea to keep the 'PATCH' word in the subject line,
> so patchwork (https://patchwork.ozlabs.org/project/openwrt/list/) will
> be able to catch your patch. Something like this:
>
> [PATCH uqmi] dms: add --get-operating-mode
>
> See also a couple of nit picks below.
>
> > commands-dms.c
> >
> > @@ -375,6 +375,38 @@ cmd_dms_reset_prepare(struct qmi_dev *qmi, struct
> > qmi_request *req, struct qmi_m
> > return QMI_CMD_REQUEST;
> > }
> >
> > +static void
> > +cmd_dms_get_operating_mode_cb(struct qmi_dev *qmi, struct qmi_request
> > *req, struct qmi_msg *msg)
> > +{
> > +struct qmi_dms_get_operating_mode_response res;
> > +
>
> This empty line is odd.
>
> > +const char *modes[] = {
>
> You could reuse 'modes' from the cmd_dms_set_operating_mode_prepare()
> to avoid duplication. Just move the array out from the function and
> call it something like 'oper_modes'.
>
> > +[QMI_DMS_OPERATING_MODE_ONLINE] = "online",
> > +[QMI_DMS_OPERATING_MODE_LOW_POWER] = "low_power",
> > +[QMI_DMS_OPERATING_MODE_FACTORY_TEST] = "factory_test",
> > +[QMI_DMS_OPERATING_MODE_OFFLINE] = "offline",
> > +[QMI_DMS_OPERATING_MODE_RESET] = "reset",
> > +[QMI_DMS_OPERATING_MODE_SHUTTING_DOWN] = "shutting_down",
> > +[QMI_DMS_OPERATING_MODE_PERSISTENT_LOW_POWER] =
> > "persistent_low_power",
> > +[QMI_DMS_OPERATING_MODE_MODE_ONLY_LOW_POWER] =
> > "mode_only_low_power",
> > +};
> > +int s = 0;
>
> This is a magic number usage. Also if a modem returns unknown value
> then the code below will report that the modem is 'online'. What can
> be misleading. See the 'get_pin_status()' function for an example of
> an unknown value handling.
>
> > +
> > +qmi_parse_dms_get_operating_mode_response(msg, &res);
> > +if (res.set.mode &&
>
> This part of the check looks odd. If res.set.mode is zero you skip the
> 's' variable updation, but s is initialized with zero during the
> definition.
>
> > +res.data.mode < ARRAY_SIZE(modes))
> > +s = res.data.mode;
> > +
> > +blobmsg_add_string(&status, NULL, modes[s]);
> > +}
> > +
> > +static enum qmi_cmd_result
> > +cmd_dms_get_operating_mode_prepare(struct qmi_dev *qmi, struct
> > qmi_request *req, struct qmi_msg *msg, char *arg)
> > +{
> > +qmi_set_dms_get_operating_mode_request(msg);
> > +return QMI_CMD_REQUEST;
> > +}
> > +
> > #define cmd_dms_set_operating_mode_cb no_cb
> > static enum qmi_cmd_result
> > cmd_dms_set_operating_mode_prepare(struct qmi_dev *qmi, struct
> > qmi_request *req, struct qmi_msg *msg, char *arg)
> >
> >
> > ---
> >
> > commands-dms.h
> >
> > @@ -37,6 +37,7 @@
> > __uqmi_command(dms_get_imsi, get-imsi, no, QMI_SERVICE_DMS), \
> > __uqmi_command(dms_get_imei, get-imei, no, QMI_SERVICE_DMS), \
> > __uqmi_command(dms_get_msisdn, get-msisdn, no, QMI_SERVICE_DMS), \
> > + __uqmi_command(dms_get_operating_mode
Re: [uqmi] dms: add --get-operating-mode
Hello Henrik,
On Sat, Dec 4, 2021 at 6:22 PM Henrik Ginstmark wrote:
> This command make it possible to query if the modem is in flight mode or not.
>
> If you need to change your APN setting it should be done during flight mode
> on.
Just curious, is this true for any Qualcomm based mode or only for a
specific model?
> To make it possible to automate change of APN setting --get-operating-mode is
> needed.
>
> Signed-off-by: Henrik Ginstmark
Your patch seems broken. Consider using git-format-patch and
git-send-email to prepare and submit the patch, please.
BTW, it is a good idea to keep the 'PATCH' word in the subject line,
so patchwork (https://patchwork.ozlabs.org/project/openwrt/list/) will
be able to catch your patch. Something like this:
[PATCH uqmi] dms: add --get-operating-mode
See also a couple of nit picks below.
> commands-dms.c
>
> @@ -375,6 +375,38 @@ cmd_dms_reset_prepare(struct qmi_dev *qmi, struct
> qmi_request *req, struct qmi_m
> return QMI_CMD_REQUEST;
> }
>
> +static void
> +cmd_dms_get_operating_mode_cb(struct qmi_dev *qmi, struct qmi_request
> *req, struct qmi_msg *msg)
> +{
> +struct qmi_dms_get_operating_mode_response res;
> +
This empty line is odd.
> +const char *modes[] = {
You could reuse 'modes' from the cmd_dms_set_operating_mode_prepare()
to avoid duplication. Just move the array out from the function and
call it something like 'oper_modes'.
> +[QMI_DMS_OPERATING_MODE_ONLINE] = "online",
> +[QMI_DMS_OPERATING_MODE_LOW_POWER] = "low_power",
> +[QMI_DMS_OPERATING_MODE_FACTORY_TEST] = "factory_test",
> +[QMI_DMS_OPERATING_MODE_OFFLINE] = "offline",
> +[QMI_DMS_OPERATING_MODE_RESET] = "reset",
> +[QMI_DMS_OPERATING_MODE_SHUTTING_DOWN] = "shutting_down",
> +[QMI_DMS_OPERATING_MODE_PERSISTENT_LOW_POWER] =
> "persistent_low_power",
> +[QMI_DMS_OPERATING_MODE_MODE_ONLY_LOW_POWER] = "mode_only_low_power",
> +};
> +int s = 0;
This is a magic number usage. Also if a modem returns unknown value
then the code below will report that the modem is 'online'. What can
be misleading. See the 'get_pin_status()' function for an example of
an unknown value handling.
> +
> +qmi_parse_dms_get_operating_mode_response(msg, &res);
> +if (res.set.mode &&
This part of the check looks odd. If res.set.mode is zero you skip the
's' variable updation, but s is initialized with zero during the
definition.
> +res.data.mode < ARRAY_SIZE(modes))
> +s = res.data.mode;
> +
> +blobmsg_add_string(&status, NULL, modes[s]);
> +}
> +
> +static enum qmi_cmd_result
> +cmd_dms_get_operating_mode_prepare(struct qmi_dev *qmi, struct
> qmi_request *req, struct qmi_msg *msg, char *arg)
> +{
> +qmi_set_dms_get_operating_mode_request(msg);
> +return QMI_CMD_REQUEST;
> +}
> +
> #define cmd_dms_set_operating_mode_cb no_cb
> static enum qmi_cmd_result
> cmd_dms_set_operating_mode_prepare(struct qmi_dev *qmi, struct
> qmi_request *req, struct qmi_msg *msg, char *arg)
>
>
> ---
>
> commands-dms.h
>
> @@ -37,6 +37,7 @@
> __uqmi_command(dms_get_imsi, get-imsi, no, QMI_SERVICE_DMS), \
> __uqmi_command(dms_get_imei, get-imei, no, QMI_SERVICE_DMS), \
> __uqmi_command(dms_get_msisdn, get-msisdn, no, QMI_SERVICE_DMS), \
> + __uqmi_command(dms_get_operating_mode, get-device-operating-mode,
> no, QMI_SERVICE_DMS), \
> __uqmi_command(dms_set_operating_mode, set-device-operating-mode,
> required, QMI_SERVICE_DMS), \
> __uqmi_command(dms_reset, reset-dms, no, QMI_SERVICE_DMS), \
> __uqmi_command(dms_set_fcc_authentication, fcc-auth, no, QMI_SERVICE_DMS)
> \
> @@ -67,6 +68,7 @@
> " --get-imei: Get International Mobile
> Equipment ID\n" \
> " --get-msisdn: Get the MSISDN (telephone
> number)\n" \
> " --reset-dms: Reset the DMS service\n" \
> + " --get-device-operating-mode Get the device operating mode\n"
> \
> " --set-device-operating-modeSet the device operating mode\n"
> \
> "(modes: online,
> low_power, factory_test, offline\n" \
> " reset, shutting_down,
> persistent_low_power,\n" \
--
Sergey
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[uqmi] dms: add --get-operating-mode
dms: add --get-operating-mode
This command make it possible to query if the modem is in flight mode or not.
If you need to change your APN setting it should be done during flight mode on.
To make it possible to automate change of APN setting --get-operating-mode is
needed.
Signed-off-by: Henrik Ginstmark
---
commands-dms.c
@@ -375,6 +375,38 @@ cmd_dms_reset_prepare(struct qmi_dev *qmi, struct
qmi_request *req, struct qmi_m
return QMI_CMD_REQUEST;
}
+static void
+cmd_dms_get_operating_mode_cb(struct qmi_dev *qmi, struct qmi_request
*req, struct qmi_msg *msg)
+{
+struct qmi_dms_get_operating_mode_response res;
+
+const char *modes[] = {
+[QMI_DMS_OPERATING_MODE_ONLINE] = "online",
+[QMI_DMS_OPERATING_MODE_LOW_POWER] = "low_power",
+[QMI_DMS_OPERATING_MODE_FACTORY_TEST] = "factory_test",
+[QMI_DMS_OPERATING_MODE_OFFLINE] = "offline",
+[QMI_DMS_OPERATING_MODE_RESET] = "reset",
+[QMI_DMS_OPERATING_MODE_SHUTTING_DOWN] = "shutting_down",
+[QMI_DMS_OPERATING_MODE_PERSISTENT_LOW_POWER] = "persistent_low_power",
+[QMI_DMS_OPERATING_MODE_MODE_ONLY_LOW_POWER] = "mode_only_low_power",
+};
+int s = 0;
+
+qmi_parse_dms_get_operating_mode_response(msg, &res);
+if (res.set.mode &&
+res.data.mode < ARRAY_SIZE(modes))
+s = res.data.mode;
+
+blobmsg_add_string(&status, NULL, modes[s]);
+}
+
+static enum qmi_cmd_result
+cmd_dms_get_operating_mode_prepare(struct qmi_dev *qmi, struct
qmi_request *req, struct qmi_msg *msg, char *arg)
+{
+qmi_set_dms_get_operating_mode_request(msg);
+return QMI_CMD_REQUEST;
+}
+
#define cmd_dms_set_operating_mode_cb no_cb
static enum qmi_cmd_result
cmd_dms_set_operating_mode_prepare(struct qmi_dev *qmi, struct
qmi_request *req, struct qmi_msg *msg, char *arg)
---
commands-dms.h
@@ -37,6 +37,7 @@
__uqmi_command(dms_get_imsi, get-imsi, no, QMI_SERVICE_DMS), \
__uqmi_command(dms_get_imei, get-imei, no, QMI_SERVICE_DMS), \
__uqmi_command(dms_get_msisdn, get-msisdn, no, QMI_SERVICE_DMS), \
+ __uqmi_command(dms_get_operating_mode, get-device-operating-mode,
no, QMI_SERVICE_DMS), \
__uqmi_command(dms_set_operating_mode, set-device-operating-mode,
required, QMI_SERVICE_DMS), \
__uqmi_command(dms_reset, reset-dms, no, QMI_SERVICE_DMS), \
__uqmi_command(dms_set_fcc_authentication, fcc-auth, no, QMI_SERVICE_DMS) \
@@ -67,6 +68,7 @@
" --get-imei: Get International Mobile
Equipment ID\n" \
" --get-msisdn: Get the MSISDN (telephone
number)\n" \
" --reset-dms: Reset the DMS service\n" \
+ " --get-device-operating-mode Get the device operating mode\n" \
" --set-device-operating-modeSet the device operating mode\n" \
"(modes: online,
low_power, factory_test, offline\n" \
" reset, shutting_down,
persistent_low_power,\n" \
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
