pppd sends LCP ConfReq then gives up

I have a ppp connection (made with pppd on a debian machine) that only
connects successfully about 1/3 of the time. The remaining times it
sends out "LCP ConfReq" until it gives up. A windows xp machine can make
the connection every time.

Every successful connection that I have looked at has only had to send
"LCP ConfReq" once before it got a response.

What could be causing this? Is it possible that my ISP has some dial in
servers configured differently to others?

I'd be grateful if somebody could help.

Details:
pppd version 2.4.3
I'm starting up using "pon lineone_myaccount"
I have a "myaccount * mypass *" entry in chap-secrets and pap-secrets

===/etc/ppp/peers/lineone_myaccount===
debug
kdebug 7
noauth
user myaccount
defaultroute
/dev/ttyS1
115200
persist
usepeerdns
lcp-max-configure 60
connect "/usr/sbin/chat -v -f /etc/chatscripts/pap -T08440404102"

===/etc/chatsripts/pap===
ABORT BUSY
ABORT VOICE
ABORT "NO CARRIER"
ABORT "NO DIALTONE"
ABORT "NO DIAL TONE"
"" ATZ
OK ATDT\T
CONNECT ""

===plog output for a failed connection===
....
Aug 9 20:10:21 xx pppd[2853]: Using interface ppp0
Aug 9 20:10:21 xx pppd[2853]: Connect: ppp0 <--> /dev/ttyS1
Aug 9 20:10:22 xx pppd[2853]: sent [LCP ConfReq id=0x1 <asyncmap 0x0>
<magic 0xe57eb509>

<pcomp> <accomp>]
Aug 9 20:10:25 xx pppd[2853]: sent [LCP ConfReq id=0x1 <asyncmap 0x0>
<magic 0xe57eb509>

<pcomp> <accomp>]
Aug 9 20:10:28 xx pppd[2853]: sent [LCP ConfReq id=0x1 <asyncmap 0x0>
<magic 0xe57eb509>

<pcomp> <accomp>]
[repeats 30 or whatever times and then finishes like:]
Aug 9 20:16:48 xx pppd[3098]: Hangup (SIGHUP)
Aug 9 20:16:48 xx pppd[3098]: sent [LCP TermReq id=0x2 "User request"]
Aug 9 20:16:51 xx pppd[3098]: sent [LCP TermReq id=0x3 "User request"]
Aug 9 20:16:54 xx pppd[3098]: Connection terminated.
Aug 9 20:16:54 xx pppd[3098]: tcflush failed: Input/output error
Aug 9 20:16:54 xx pppd[3098]: Modem hangup

===/etc/ppp/options===
asyncmap 0
auth
crtscts
lock
hide-password
modem
proxyarp
lcp-echo-interval 30
lcp-echo-failure 4
noipx

Ian <(E-Mail Removed)> writes:

>I have a ppp connection (made with pppd on a debian machine) that only
>connects successfully about 1/3 of the time. The remaining times it
>sends out "LCP ConfReq" until it gives up. A windows xp machine can make
>the connection every time.

I can make and windows machine never connect.
Misconfiguration will do that to you, on any operating system.


>Every successful connection that I have looked at has only had to send
>"LCP ConfReq" once before it got a response.

>What could be causing this? Is it possible that my ISP has some dial in
>servers configured differently to others?

Many many things could cause this.


>I'd be grateful if somebody could help.

>Details:
>pppd version 2.4.3
>I'm starting up using "pon lineone_myaccount"
>I have a "myaccount * mypass *" entry in chap-secrets and pap-secrets

>===/etc/ppp/peers/lineone_myaccount===
>debug
>kdebug 7

kdebug no longer works. Remove.

>noauth
>user myaccount
>defaultroute
>/dev/ttyS1
>115200
>persist
>usepeerdns
>lcp-max-configure 60
>connect "/usr/sbin/chat -v -f /etc/chatscripts/pap -T08440404102"

>===/etc/chatsripts/pap===
>ABORT BUSY
>ABORT VOICE
>ABORT "NO CARRIER"
>ABORT "NO DIALTONE"
>ABORT "NO DIAL TONE"
>"" ATZ
>OK ATDT\T
>CONNECT ""

Horrible. This sends a carriage return after the connect. That can totally
confuse the system at the other end
CONNECT '\d\c'
is the proper way to end
(That means pause for one second and then do NOT send a carriage return)




>===plog output for a failed connection===
>...
>Aug 9 20:10:21 xx pppd[2853]: Using interface ppp0
>Aug 9 20:10:21 xx pppd[2853]: Connect: ppp0 <--> /dev/ttyS1
>Aug 9 20:10:22 xx pppd[2853]: sent [LCP ConfReq id=0x1 <asyncmap 0x0>
><magic 0xe57eb509>

><pcomp> <accomp>]
>Aug 9 20:10:25 xx pppd[2853]: sent [LCP ConfReq id=0x1 <asyncmap 0x0>
><magic 0xe57eb509>

><pcomp> <accomp>]
>Aug 9 20:10:28 xx pppd[2853]: sent [LCP ConfReq id=0x1 <asyncmap 0x0>
><magic 0xe57eb509>

><pcomp> <accomp>]
>[repeats 30 or whatever times and then finishes like:]
>Aug 9 20:16:48 xx pppd[3098]: Hangup (SIGHUP)
>Aug 9 20:16:48 xx pppd[3098]: sent [LCP TermReq id=0x2 "User request"]
>Aug 9 20:16:51 xx pppd[3098]: sent [LCP TermReq id=0x3 "User request"]
>Aug 9 20:16:54 xx pppd[3098]: Connection terminated.
>Aug 9 20:16:54 xx pppd[3098]: tcflush failed: Input/output error
>Aug 9 20:16:54 xx pppd[3098]: Modem hangup

Yes, exactly what I would expect. Teh other side wants you to log on or
something and you want to negotiate ppp. This is like betting Bush and
binLaden into a negotiation together. Not likely to have a happy outcome.



>===/etc/ppp/options===
>asyncmap 0
>auth
>crtscts
>lock
>hide-password
>modem
>proxyarp
>lcp-echo-interval 30
>lcp-echo-failure 4

Why do you have these lcp things?

And if you are the one calling an isp, proxyarp is totally inappropriate.
you instead want defaultroute probably if that ISP is your default route
gateway.



>noipx

Ian <(E-Mail Removed)> wrote:
> I have a ppp connection (made with pppd on a debian machine) that only
> connects successfully about 1/3 of the time. The remaining times it
> sends out "LCP ConfReq" until it gives up. A windows xp machine can make
> the connection every time.

> Every successful connection that I have looked at has only had to send
> "LCP ConfReq" once before it got a response.

> What could be causing this? Is it possible that my ISP has some dial in
> servers configured differently to others?

Yes, or have connection hosts (servers) with completely different PPP
implementations. The carriage-return sent by

CONNECT ""

in /etc/chatsripts/pap can trigger a login prompt for some "servers"
that's not appropriate for ISP clients while others just ignore the
carriage-return. Bill Unruh's suggested replacement

CONNECT \d\c

should cure that. His other suggestions are reasonable but it's very
likely this replacement alone will allow PPP negotiations to complete.

Remove the " lcp-max-configure 60 " option. If you send 10 (the default
maximum) LCP requests that fail to get a response then it's extremely
unlikely that PPP negotiations will succeed simply by increasing the
number. The ISP host in the case of the failed connection appears to
have timed out waiting for a login and hung up.

--
Clifford Kite Email: "echo xvgr_yvahk-(E-Mail Removed)|rot13"

> Bill Unruh's suggested replacement
>
> CONNECT \d\c
>
> should cure that.

Ok, thanks. For the record that seems to have fixed it. I'm a little
suprised though; the chatscript installed with the OS.