🚀 go-pugleaf

Bob Wightman <Bob@pattindaughter.demon.co.uk> writes:
> Mar 19 20:52:26 linux pppd[780]: local  IP address 158.152.147.15
> Mar 19 20:52:26 linux pppd[780]: remote IP address 158.152.1.222

Up to here, the establishment is pretty normal.

> Mar 19 20:54:22 linux pppd[780]: sent [LCP EchoReq id=0x4
> magic=0xb31984a5]
> Mar 19 20:54:52 linux pppd[780]: sent [LCP EchoReq id=0x5
> magic=0xb31984a5]
> Mar 19 20:55:22 linux pppd[780]: No response to 4 echo-requests

Something bad happened to either the underlying physical link or the
peer's PPP implementation.  There are a few suspects, though:

> Here is /etc/ppp/options
[...]
> lcp-max-configure 60
> lcp-restart 2

Are you sure you need those?  That looks like excessive tuning to me.
(This almost certainly isn't the cause of the problem, but it's
strange.)

> asyncmap  200a0000

That doesn't match what the peer is asking for (0).  There are enough
broken implementations in the world now that asking for exactly the
same ACCM that you get from the peer is really the best way to go.
Just remove this line -- the default is 0 anyway.

> Here is my chat-script:
> 
> ABORT BUSY
> ABORT "NO CARRIER"
> "" ATZ
> OK ATDT08452120666
> CONNECT ""

That doesn't look good.  You don't configure the modem at all.  Are
you *SURE* that the profile restored by "ATZ" is exactly the right one
for PPP?

In most cases, something like "AT&F1" or "AT&F&C1&D2" works right.
You may also need to set "ATS2=255".

I suspect that the modem has some form of software flow control
enabled by default, and that's what's causing the link failure.

-- 
James Carlson, Solaris Networking         <james.d.carlson@east.sun.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