New ISP, new problems

New ISP, new problems

Post by hugovanwoe » Tue, 09 Dec 2003 06:20:09


Hi list!

I switched ISP's from Mexican Prodigy to Mexican AT&T.

Interesting: I always thought the maximum 8 hours connection was
Telmex's doing (the national telco), it isn't: it is Prodigy: max 8
hours connect, and lots of sighups at other times too. *Stay away from
Prodigy in Mexico*.

Now with AT&T the connect limit is gone but now, at times (once a
day?), I get:

Dec 7 14:35:16 debian pppd[7618]: No response to 4 echo-requests
Dec 7 14:35:16 debian pppd[7618]: Serial link appears to be
disconnected.

and my pppd hangs up.

Does it make sense to set lcp-echo-failure and lcp-echo-interval to
see if they will start responding?

It seems to happen at random: not at any specified interval.

What would make their end do this?

Thanks!

Hugo
 
 
 

New ISP, new problems

Post by James Carl » Tue, 09 Dec 2003 20:36:51


XXXX@XXXXX.COM (hugo vanwoerkom) writes:

I've never seen such a thing imposed by a telco, though I suppose it
would be possible. Time limits are almost always set by the ISP.


It doesn't make sense because you must *ALREADY* have set them if
you're seeing that message above. By default, pppd does not do LCP
Echo-Request testing, and will never cause the disconnect you're
seeing.

Check your pppd configuration files. You must have those parameters
in there somewhere. Check to see if perhaps the specified interval or
maximum number of failures is too small to accomodate "normal" events,
such as modem retraining.


Their end isn't doing that -- yours is both sending the Echo-Request
messages and disconnecting due to a lack of response.

If their end is failing to respond, and if it's not just a modem
problem, and if the link itself is still passing IP traffic, then I
don't know what would do that.

--
James Carlson, Solaris Networking < XXXX@XXXXX.COM >
Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677

 
 
 

New ISP, new problems

Post by hugovanwoe » Tue, 09 Dec 2003 23:56:42


Absolutely right: they are set in the options file: interval set to 30
and failure to 4. I failed to check first if I had those parms set. I
apologize. But thanks for the response! Very helpful.

On the sighups by Prodigy: I posted the problem on this list once but
I again failed to realize that they would never be imposed by the
telco.

Hugo.
 
 
 

New ISP, new problems

Post by James Carl » Wed, 10 Dec 2003 00:14:02


XXXX@XXXXX.COM (hugo vanwoerkom) writes:

Four failures at 30 seconds is a 2 minute outage -- that's a really
long time, and I don't think it can be accounted for by any "normal"
modem problem. If you're seeing such a failure to respond to LCP
Echo-Request messages, then one of two things would seem to be true:

- The ISP really does have such failures. They simply go dead
without *** up the phone. The link is completely
useless, and pppd is doing the right thing by tearing it
down. Use the "persist" option if you'd like pppd to try
again.

or:

- The ISP has some sort of bug that prevents it from
responding to LCP Echo-Request correctly, but the link is
otherwise still usable for IP. I doubt that this is really
the case, but I suppose anything is possible.

To test this, try removing the lcp-echo-failure option, but leave
lcp-echo-interval in place. Run pppd with debug, and once the link
stops responding to LCP Echo-Request, see if IP still works. If it
does, then the latter (albeit unlikely) case is true. Otherwise, it's
the former.


I wouldn't say "never" -- just very unlikely.

--
James Carlson, Solaris Networking < XXXX@XXXXX.COM >
Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677