ppp modem not getting reset properly

[Brandon Pedersen]

Hi, I have configured ppp to start on boot by creating the /etc/ppp/ppp_on_boot file and am testing out the init script. I am noticing something weird. I run /etc/init.d/ppp start and it will fire up the connection OK, then I run /etc/init.d/ppp stop and it shuts down the connection (though I had to modify the poff script to correctly detect there was only one instance of pppd running). When I try to start the connection again I get an error:

ov 10 13:21:36 mtcdp daemon.notice pppd[2400]: pppd 2.4.3 started by root, uid 0

Nov 10 13:21:36 mtcdp daemon.err pppd[2400]: Failed to open /dev/ttyUSB4: Input/output error

Nov 10 13:21:36 mtcdp daemon.info pppd[2400]: Exit.

If I run the init script again it will start OK. So any idea why it is not resetting the modem properly the first time?

[Jesse Gilles]

Does this happen regardless of the time between the /etc/init.ppp stop and start…or does waiting for a while fix it? Just curious — I’m not sure why this is happening, it’s not something I’ve seen. Is it happening consistently?

When you refer to “resetting the modem”, are you actually resetting the modem by pulling the reset line using mts-io? Or are you just referring to ppp releasing the modem port when it’s done with it?

[Brandon Pedersen]

Ugh, this is driving me nuts!

Yes, this behavior is consistent. I am not sure if there is a difference if I wait longer….I may have waited at most 5 minutes between trying to reconnect like this, maybe…I will try to wait for longer and see if that helps.

I forgot about the mts-io stuff, I was just referring to ppp releasing the modem.

I tried to reset the radio by doing echo 0 > /sys/devices/platform/mtcdp/radio-reset and then fired up the connection but then I got some error during the chat script trying to connect, I may have needed to wait a little longer there.

Maybe there is something wrong with the chat script…I didn’t change it much from the default, just changed the APN.

I just want to get a reliable connection running that will always be started when the device boots and will automatically retry if there is a failure. I tried adding the ‘persist’ option to the gsm script but if the modem didn’t get hung up or reset properly or if there was some other error connecting it doesn’t retry and leaves ppp hanging around doing nothing.

[Brandon Pedersen]

I forgot to mention, I modified the gsm script on the connect line to add echo ‘AT!RESET’ > /dev/ttyUSB4, so:

connect ‘echo “AT!RESET” > /dev/ttyUSB4; /usr/sbin/chat -v -t 90 -f /etc/ppp/peers/gsm_chat’

And that appears to help my original situation, but I am still worried that if for some reason the remote peer doesn’t respond properly the connection will fail and I will have no way of communicating with the device…maybe I should go with your suggestion from the other post and create a ppp connection watchdog script and setup cron to run that.

[Lonny Knudson]

A common method used in cellular applications is to have a process that periodically tests the IP layer (example: by attempting to ping a known good address on the remote end of the cellular link) and resetting the cellular modem (and restarting pppd) in the event that the IP transport appears unresponsive. This approach has proven to be very robust way to make sure the cellular link is always up. The tradeoff is that the IP test generates billable traffic on the cellular account so you need to be mindful if your provider charges fees for going over the data usage limit.

[Brandon Pedersen]

OK, so I think I have it working well enough. I created a watchdog script and added it to cron and with my addition to the gsm connect script I think it will work OK.

You are right about the generated data, I just set it to run once every 10 minutes and only does a one byte ping so it shouldn’t be too bad.

[Author]

Posts