Re: Resetting Bearer on OpenWRT
On Mon, Oct 15, 2018 at 3:12 AM Aleksander Morgado wrote: > > Hey! > > > I'm running modemmanager on OpenWRT and am getting this error fairly > > regularly such as when I use AT commands to manually change LTE > > bands(is there a better way to change/lock bands than using AT > > commands?): "Bearer not allowed to connect, not registered in 3GPP > > network" > > > > If you're using ModemManager, you can also use mmcli directly, e.g. > "mmcli -m 0 --set-current-bands="eutran-2|eutran-3|eutran-4" > The list of supported bands should be given in the "mmcli -m 0" > output. Changing bands, of course, will trigger a network > unregistration and re-registration, and so the device will get > unregistered in the process. > > > Doing "ifup broadband" resolves the issue(at least until it loses the > > bearer again) since resetting the interface triggers > > proto_modemmanager_setup() to flush and reset the bearer but I don't > > see a way to automatically get modemmanager state change notifications > > to OpenWRT so that I can trigger the bearer reload directly from the > > modemmanger state change event. I assume that's because modemmanager > > uses dbus and OpenWRT uses ubus right? I've used a cron job as a > > workaround to monitor the bearer and issue an "ifup broadband" when > > it's lost. > > > > One thing you need to consider is that, if I'm not mistaken, the > netifd integration done in OpenWRT does *not* consider automatic > reconnections. So if your modem gets disconnected due to any reason > (e.g. unregistered from the network because you changed bands in use) > then you'll need to manually trigger a reconnection (e.g. with "ifup > broadband" as you were doing). I'm sure this can be changed somehow to > autoreconnect, but didn't spend much time on that after doing the > initial MM integration in OpenWRT. > > The script you're using, where you just look for the bearer state in > MM and trigger a manual interface up event in netifd if the bearer is > disconnected, is one way to have the automatic reconnection logic > working, yes :) How difficult would it to be to add minimal ubus support for triggering automatic re-connections as a compile time option? > > -- > Aleksander > https://aleksander.es ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Resetting Bearer on OpenWRT
> > > I'm running modemmanager on OpenWRT and am getting this error fairly > > > regularly such as when I use AT commands to manually change LTE > > > bands(is there a better way to change/lock bands than using AT > > > commands?): "Bearer not allowed to connect, not registered in 3GPP > > > network" > > > > > > > If you're using ModemManager, you can also use mmcli directly, e.g. > > "mmcli -m 0 --set-current-bands="eutran-2|eutran-3|eutran-4" > > The list of supported bands should be given in the "mmcli -m 0" > > output. Changing bands, of course, will trigger a network > > unregistration and re-registration, and so the device will get > > unregistered in the process. > > > > > Doing "ifup broadband" resolves the issue(at least until it loses the > > > bearer again) since resetting the interface triggers > > > proto_modemmanager_setup() to flush and reset the bearer but I don't > > > see a way to automatically get modemmanager state change notifications > > > to OpenWRT so that I can trigger the bearer reload directly from the > > > modemmanger state change event. I assume that's because modemmanager > > > uses dbus and OpenWRT uses ubus right? I've used a cron job as a > > > workaround to monitor the bearer and issue an "ifup broadband" when > > > it's lost. > > > > > > > One thing you need to consider is that, if I'm not mistaken, the > > netifd integration done in OpenWRT does *not* consider automatic > > reconnections. So if your modem gets disconnected due to any reason > > (e.g. unregistered from the network because you changed bands in use) > > then you'll need to manually trigger a reconnection (e.g. with "ifup > > broadband" as you were doing). I'm sure this can be changed somehow to > > autoreconnect, but didn't spend much time on that after doing the > > initial MM integration in OpenWRT. > > > > The script you're using, where you just look for the bearer state in > > MM and trigger a manual interface up event in netifd if the bearer is > > disconnected, is one way to have the automatic reconnection logic > > working, yes :) > How difficult would it to be to add minimal ubus support for triggering > automatic re-connections as a compile time option? > > Absolutely no idea, because I don't know how netifd expects that to be reported or how it does connection monitoring. Any info on how that works would be appreciated. -- Aleksander https://aleksander.es ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Resetting Bearer on OpenWRT
Hi! On Sun, 8 Sep 2019, Aleksander Morgado wrote: Absolutely no idea, because I don't know how netifd expects that to be reported or how it does connection monitoring. Any info on how that works would be appreciated. I admit I didn't follow the entire discussion from the beginning, so sorry for the noise in case what I am telling is useless. From my unerstanding, anyone please correct me if I am wrong, lots of relevant code is in OpenWRt's netifd-proto.sh. From my understanding, netifd expects to be informed by protocol handlers about when things change, especially because in this case the network interface wouldn't change it's state apparently. So, as righly pointed out by you, MM may directly emit ubus events simulating what a protocol handler does, or it may invoke a shell script carrying out that task, keeping the state consistent. This is what I did in AGH - I am not saying it's the best solution, but that's the route I choose. Enrico ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
RE: Resetting Bearer on OpenWRT
Hi Enrico, Can you please share what you did to address this? I think this is very much desired enhancement especially when the signal is not that great and there and frequent disconnections/reconnections occurring. Thanks Amol The information in this email communication (inclusive of attachments) is confidential to 4RF Limited and the intended recipient(s). If you are not the intended recipient(s), please note that any use, disclosure, distribution or copying of this information or any part thereof is strictly prohibited and that the author accepts no liability for the consequences of any action taken on the basis of the information provided. If you have received this email in error, please notify the sender immediately by return email and then delete all instances of this email from your system. 4RF Limited will not accept responsibility for any consequences associated with the use of this email (including, but not limited to, damages sustained as a result of any viruses and/or any action or lack of action taken in reliance on it).-Original Message- From: ModemManager-devel On Behalf Of Enrico Mioso Sent: Sunday, 8 September 2019 12:55 PM To: Aleksander Morgado Cc: ModemManager (development) ; James Hilliard Subject: Re: Resetting Bearer on OpenWRT Hi! On Sun, 8 Sep 2019, Aleksander Morgado wrote: > Absolutely no idea, because I don't know how netifd expects that to be > reported or how it does connection monitoring. Any info on how that > works would be appreciated. I admit I didn't follow the entire discussion from the beginning, so sorry for the noise in case what I am telling is useless. From my unerstanding, anyone please correct me if I am wrong, lots of relevant code is in OpenWRt's netifd-proto.sh. From my understanding, netifd expects to be informed by protocol handlers about when things change, especially because in this case the network interface wouldn't change it's state apparently. So, as righly pointed out by you, MM may directly emit ubus events simulating what a protocol handler does, or it may invoke a shell script carrying out that task, keeping the state consistent. This is what I did in AGH - I am not saying it's the best solution, but that's the route I choose. Enrico ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
modemmanager/qmicli openwrt feed update
Hi Aleksander, If you consider this ok, then can you please update the modemmanager and qmicli to the latest release in openwrt feed? They are currently at 1.10.0 and 1.22.4 respectively. Thanks Amol The information in this email communication (inclusive of attachments) is confidential to 4RF Limited and the intended recipient(s). If you are not the intended recipient(s), please note that any use, disclosure, distribution or copying of this information or any part thereof is strictly prohibited and that the author accepts no liability for the consequences of any action taken on the basis of the information provided. If you have received this email in error, please notify the sender immediately by return email and then delete all instances of this email from your system. 4RF Limited will not accept responsibility for any consequences associated with the use of this email (including, but not limited to, damages sustained as a result of any viruses and/or any action or lack of action taken in reliance on it). ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
