On 23/03/2014 00:43, Mike McClain wrote:
In /etc/ppp/options lcp-echo-interval 30 and lcp-echo-failure is
unset.
I've got ppp error logging going to tty12 and /var/log/debug and
often see entries such as this:
Mar 22 16:03:23 playground pppd[20465]: sent [LCP EchoReq id=0x2 magic=0x84f3fde5]
Mar 22 16:03:23 playground pppd[20465]: rcvd [LCP EchoRep id=0x2 magic=0x0]
Mar 22 16:03:53 playground pppd[20465]: sent [LCP EchoReq id=0x3 magic=0x84f3fde5]
Mar 22 16:03:53 playground pppd[20465]: rcvd [LCP EchoRep id=0x3 magic=0x0]
Mar 22 16:04:23 playground pppd[20465]: sent [LCP EchoReq id=0x4 magic=0x84f3fde5]
Mar 22 16:04:49 playground pppd[20465]: Modem hangup
Mar 22 16:04:49 playground pppd[20465]: Connect time 2.5 minutes.
Mar 22 16:04:49 playground pppd[20465]: Sent 124 bytes, received 261 bytes.
In this case the hangup occurred 26 Seconds after the EchoReq was sent
but I've seen it hangup as little as 2 seconds after sending EchoReq or
receiving EchoRep.
[.....]
I've seen times in the logs where the ISP quit sending EchoReq for several
minutes at a time but my system didn't disconnect until I told it to.
Good start. Could you also post the LCP setup/connection entries in the log, for a case where the connection subsequently fails? I would suggest checking to be sure that the link is coming up correctly, so that, perhaps, the setup phase can be ruled out, and concentrate on the traffic transfer states.
I can see why you want to have the modem commands/statuses but I think the only thing they will very clearly show will be whether the
modem hangupis occurring as a response to carrier removal by the ISP (including a poor line, in fact), or as an own-initiative decision by your own pppd (or LCP) to drop the connection. In either case, the modem hangup is a symptom, I think, and the events prior to that, at the protocol level, will be the causes, and where clues will be found. Nevertheless, the data can probably be logged, but I've never tried to do so; sadly, I can't explain how to do that.
The LCP link establishment log (the earlier section of what you've already posted) will be worth checking, to be sure that all is well. If you don't want to post it, then just get two of them, one for a working session, and one for a session that fails, and very carefully compare them; post back any differences you find.
Could you also look at man pppd again, and check whether the additional config files that it describes contain anything that alters settings in /etc/ppp/options? The other thing to check would be the command line calling pon because parameters given pon can override the standard options, as well.
On options: Is crtscts set in 'options'?Though you said you've redirected the log to /var/log/debug, did you set the debug option?
The dump option will place all the option settings that are in use, irrespective of which file or command line they are sourced from, into the log; I suggest you do that.
kdebug option will list the packets sent/received by the kernel driver. As a last resort you could do this, but I fear it will be pages of hexadecimal. kdebug 7 will list general driver debug, sent, and received packets.
regards, Ron