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 hangup
is 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
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/532f3351.3010...@tesco.net
