Conduit unable to recover from loss of cellular connection until restart.

[Ajay K]

We are facing an issue with some of our conduits located in our various customer locations with a clear line of sight to the Cellular towers. Also this is a conduit with Verizon modem.

We have already swapped conduits and sim cards attempting to fix this issue of loss of cellular connection after few hours of the Conduit being powered on. The only thing that seems to fix the issue is reboot of the conduit and this is turning out to be an expensive and operational issue given the remote area where these conduits are located. Also we are on Conduit firmware version 1.7.4.

So we were hoping to figure a way to handle this via code, such as restarting the PPP service or resetting the cellular/radio modem? The conduit web api calls out executing some commands at this link

Are there any examples on how to use those commands? A while back there used to be pdf file which described Conduit web api and how to use any of these commands, requests and response? But I couldn’t find it anywhere on the site?

Also would you recommend executing these commands related to the cellular modem and PPP service, in order to recover from the cellular connection loss.

Thanks,
Ajay.

[Ajay K]

Any thoughts as this is affecting our ability to connect to the conduits in these remote locations?

[Jason Reiss]

API doc is here.
http://www.multitech.net/developer/software/mtr-software/mtr-api-reference/

You may want to open a ticket to share logs, config, model and firmware info.
https://support.multitech.com

[Ajay K]

Hi Jason,

Thanks for taking the time to respond. That is the same link I called out on this thread. Wasn’t there a pdf file which had clear examples for each of the endpoints on what needs to be posted for the http post scenarios such as when executing the commands?

Meanwhile I will also open a ticket.

Thanks,
Ajay

[Jason Reiss]

Not sure where the old doc went.

https://www.multitech.com/brands/multiconnect-conduit

Normally I look the the calls made by the UI in a browser debug window to see json examples of API calls.

[Ajay K]

Hi Jason,

Needed some guidance on this issue we are facing. Currently as mentioned earlier in the thread. As of now we are having to take the extreme step of restarting the conduit for the conduit to successfully connect to the Verizon network. I was wondering if resetting the modem via the conduit API would have the same effect and prevent us from having to restart the conduit?

We are planning to call a post request of the above mentioned URL :

http://127.0.0.1/api/command/reset_modem

Thanks,
Ajay

[Ajay K]

Can I get some information regarding the PPP service? What is it specifically mean to stop, start and toggle the PPP Service? I see commands for all this under the command endpoint api, i.e. as mentioned below:

http://127.0.0.1/api/command/ppp_stop
http://127.0.0.1/api/command/ppp_start
http://127.0.0.1/api/command/ppp_toggle

Thanks,
Ajay

[Jeff Hatch]

Hello Ajay,

The ppp_stop command will stop pppd and leave it that way. Same for ppp_start, starts pppd. These two commands run “/etc/init.d/ppp stop|start”.

The ppp toggle is kind of weird in that I do not know exactly what it’s use is, but all it does is check if pppd is running, and if it is it will stop it. If pppd is not running, it will start it. From an external viewpoint if I were using the API I don’t know when I would use it because as with any normal programming I would always want things to be as deterministic as possible (am I starting it or stopping it?). Just my two cents.

Jeff

[Ajay K]

Hi Jeff,

We used the PPP stop and start and it helped us recover in these scenarios where the connection fails and the conduit doesn’t seem to recover once the connection is lost.

Thanks,
Ajay

[Ajay K]

Just wanted some clarification regarding this setting under cellular configuration in the conduit. Is this rebooting the PPP service or is it resetting the Radio modem? Also does it reset the modem or restart the PPP service after 2 hours as mentioned in the help section for this setting? I am little unclear by enabling this feature when/how does it decide to reboot the radio? Also I am unclear about the warning about potentially being blacklisted by the carrier?

Radio Reboot Enabled

Enable or disable radio reboot (default: disabled). Used in the rare case where a PPP connection has failed for two hours or more. When enabled, this feature restarts the radio. The pppcheck (ICMP/TCP Check) feature must also be enabled.
NOTE: Use this feature with discretion. While it attempts to wait for either the back-off timers to be fully exercised or ping failure for at least two hours, there is a possibility your radio could get black-listed by your network carrier if it attempts to reconnect too frequently.

Thanks,
Ajay

[Steve Kovarik]

Hi Ajay

With radio reboot enabled, the keep alive feature will stop PPP, reboot the radio then re-start PPP if the ICMP/TCP keep alive check fails in the configured time interval. In the vast majority of installations using keep alive with radio reboot disabled is adequate to recover the link.
The cautionary note is for configuring too short of an interval and with radio reboot enabled could incur frequent registration and connection attempts.

[Jeff Hatch]

Hello Ajay,

The API ppp_start and ppp_stop commands restart ppp only (or WWAN if that is being used). It does not reset the radio.

As you observed with the radio reboot feature there is the warning. That warning is because that feature attempts to use the back-off timers, and the fact that the algorithm is rather complex, ie. complex enough that it is very, very difficult to be sure that all possible combinations are tested. With that feature we cannot guarantee that it will NOT introduce behavior such as attempting to reconnect or re-register (due to resetting the radio) too frequently and get the radio blacklisted.

The back-off timers are used for the ppp connection in the ICMP-TCP keep-alive feature because some providers have required that behavior, and there is still a potential that the radio could be blacklisted with those providers if we do not follow the timers (for simply trying to reconnect too frequently). However, with the networks the way they are now with LTE, I am not sure that the back-off timers are required anymore.

What all this means is that you might want to talk with your provider to make sure that you will not have problems if you try to reconnect too often. Clear as mud? Welcome to my world:)

Thank You,

Jeff

[Ajay K]

Hi Jeff/Steve,

Thanks for taking the time to help and clarify this feature. I can check with Verizon to see if they have any opinion on if they would end up having blacklisting or any other practice they may have if we turn on this feature and would potentially reconnect too often.

Thanks,
Ajay

[Author]

Posts