pppd dials, but fails to connect

Hello,

When I dial using minicom and start pppd -d -detach /dev/ttyS1 38400 I
get the following output:

pppd -d -detach /dev/ttyS1 38400
using channel 6
Using interface ppp0
Connect: ppp0 <--> /dev/ttyS1
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xdf5e9901> <pcomp>
<accomp>]
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xdf5e9901> <pcomp>
<accomp>]
rcvd [LCP ConfReq id=0x61 <asyncmap 0xa0000> <auth pap> <magic
0x62c92be7> <pcomp> <accomp>]
sent [LCP ConfRej id=0x61 <auth pap>]
rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0xdf5e9901> <pcomp>
<accomp>]
rcvd [LCP ConfReq id=0x62 <asyncmap 0xa0000> <auth pap> <magic
0x62c92be7> <pcomp> <accomp>]
sent [LCP ConfRej id=0x62 <auth pap>]
rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0xdf5e9901> <pcomp>
<accomp>]
rcvd [LCP ConfReq id=0x63 <asyncmap 0xa0000> <auth pap> <magic
0x62c92be7> <pcomp> <accomp>]
sent [LCP ConfRej id=0x63 <auth pap>]
rcvd [LCP ConfReq id=0x64 <asyncmap 0xa0000> <auth pap> <magic
0x62c92be7> <pcomp> <accomp>]
sent [LCP ConfRej id=0x64 <auth pap>]
rcvd [LCP ConfReq id=0x65 <asyncmap 0xa0000> <auth pap> <magic
0x62c92be7> <pcomp> <accomp>]
sent [LCP ConfRej id=0x65 <auth pap>]
rcvd [LCP ConfReq id=0x66 <asyncmap 0xa0000> <auth pap> <magic
0x62c92be7> <pcomp> <accomp>]
sent [LCP ConfRej id=0x66 <auth pap>]
rcvd [LCP TermReq id=0x67]
sent [LCP TermAck id=0x67]
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xdf5e9901> <pcomp>
<accomp>]
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xdf5e9901> <pcomp>
<accomp>]
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xdf5e9901> <pcomp>
<accomp>]
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xdf5e9901> <pcomp>
<accomp>]
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xdf5e9901> <pcomp>
<accomp>]
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xdf5e9901> <pcomp>
<accomp>]
Modem hangup
Connection terminated.

My /etc/ppp/options contains the following data:

defaultroute
lock
debug
name <loginname>
idle 60

and my /etc/ppp/pap-secrets the following:

# Secrets for authentication using PAP
# client server secret IP addresses
<loginname> * <pass>

the ppp-on script as described in the howto does not work at all, but
I thought I might have to solve this problem first.

Please let me know if you have a sollution for this problem.

Sincerely,
Rene van Lieshout

Rene van Lieshout <(E-Mail Removed)> wrote:

> When I dial using minicom and start pppd -d -detach /dev/ttyS1 38400 I
> get the following output:

> pppd -d -detach /dev/ttyS1 38400
> using channel 6
> Using interface ppp0
> Connect: ppp0 <--> /dev/ttyS1
> sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xdf5e9901> <pcomp>
> <accomp>]
> sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xdf5e9901> <pcomp>
> <accomp>]
> rcvd [LCP ConfReq id=0x61 <asyncmap 0xa0000> <auth pap> <magic
> 0x62c92be7> <pcomp> <accomp>]
> sent [LCP ConfRej id=0x61 <auth pap>]

Ect.

> Modem hangup
> Connection terminated.

> My /etc/ppp/options contains the following data:

> defaultroute
> lock
> debug
> name <loginname>
> idle 60

> and my /etc/ppp/pap-secrets the following:

> # Secrets for authentication using PAP
> # client server secret IP addresses
> <loginname> * <pass>

Pppd rejects the PAP authentication requested by the peer. That means
pppd cannot find a secrets line in pap-secrets that matches the username
for the user (or name) option. I.e., the username for the option differs
in some respect from the username in pap-secrets. If the username has
any non-alphanumeric characters then it should be quoted ''.

> the ppp-on script as described in the howto does not work at all, but
> I thought I might have to solve this problem first.

The PPP howto isn't very good. Try this site:

http://www.theory.physics.ubc.ca/ppp-linux.html

> Please let me know if you have a sollution for this problem.

There are some PPP+chat connection scripts at the web site in my
signature in the downloads section. Minicom isn't the way to go.

--
Clifford Kite Email: "echo xvgr_yvahk-(E-Mail Removed)|rot13"
PPP-Q&A links, downloads: http://ckite.no-ip.net/
/* "Be liberal in what you accept, and conservative in what you send"
RFC 1122 */

Clifford Kite <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>...
> There are some PPP+chat connection scripts at the web site in my
> signature in the downloads section. Minicom isn't the way to go.

I used some of your scripts and I can get a working connection now.
Thank you for that

I used the following commands:

export UserName='<user>'
export Telephone=<phone>
export ModemInit='ATZ\&F OK AT S7=45 S0=0 L1 V1 X4 \&c1 E1 Q0'

exec /usr/sbin/pppd connect '/usr/sbin/chat -v ABORT "NO DIALTONE" \
ABORT BUSY ABORT "NO CARRIER" ABORT "PROTOCOL: NONE" ABORT ERROR \
"" AT\&F OK ATDT${Telephone} CONNECT \\c' \
/dev/ttyS1 user ${UserName} 115200 lock debug crtscts asyncmap 0
defaultroute \
demand idle 60 ipcp-accept-local ipcp-accept-remote
192.168.0.100:192.168.0.101 \
noipdefault holdoff 0 -detach

The only problmen now is that it always calls in. Can I see why it's
calling in? Could it be that I'm connecting myself using ssh (since
that is network traffic).

(E-Mail Removed) (Rene van Lieshout) writes:

]Clifford Kite <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>...
]> There are some PPP+chat connection scripts at the web site in my
]> signature in the downloads section. Minicom isn't the way to go.

]I used some of your scripts and I can get a working connection now.
]Thank you for that

]I used the following commands:

]export UserName='<user>'
]export Telephone=<phone>
]export ModemInit='ATZ\&F OK AT S7=45 S0=0 L1 V1 X4 \&c1 E1 Q0'

]exec /usr/sbin/pppd connect '/usr/sbin/chat -v ABORT "NO DIALTONE" \
]ABORT BUSY ABORT "NO CARRIER" ABORT "PROTOCOL: NONE" ABORT ERROR \
]"" AT\&F OK ATDT${Telephone} CONNECT \\c' \
]/dev/ttyS1 user ${UserName} 115200 lock debug crtscts asyncmap 0
]defaultroute \
]demand idle 60 ipcp-accept-local ipcp-accept-remote
]192.168.0.100:192.168.0.101 \
]noipdefault holdoff 0 -detach

]The only problmen now is that it always calls in. Can I see why it's
]calling in? Could it be that I'm connecting myself using ssh (since
]that is network traffic).
Yes, ssh is network traffic and goes out to the hosts in /etc/resolv.conf to
resolve the host names. Even if you tell the system to use /etc/hosts first and
the machine is in /etc/hosts, ssh will also go to the resolvers.

Michael Buchenrieder <(E-Mail Removed)> writes:

](E-Mail Removed) (Rene van Lieshout) writes:

][...]

]>The only problmen now is that it always calls in. Can I see why it's
]>calling in? Could it be that I'm connecting myself using ssh (since
]>that is network traffic).

]man tcpdump, although the typical suspect would be name resolving.
]Tip: Add your local machine name(s) into /etc/hosts.

It does not help with ssh. ssh ALWAYS goes to the resolver. It uses the
new getaddrinfo instead of the old gethostbyname routines. the new one ALWAYS
goes to the resolver in /etc/resolv.conf even if the name is found in /etc/hosts.
Stupid Stupid behaviour, and if you have any clout with the resolver glibc maintainers
get them to change this. But it seems to be a Feature(TM) which they are going to force
on the world because of some religious beliefs they have. (/etc/hosts SHOULD NOT be used
for anything but booting up).

(E-Mail Removed) (Bill Unruh) writes:

>Michael Buchenrieder <(E-Mail Removed)> writes:

>](E-Mail Removed) (Rene van Lieshout) writes:

>][...]

>]>The only problmen now is that it always calls in. Can I see why it's
>]>calling in? Could it be that I'm connecting myself using ssh (since
>]>that is network traffic).

>]man tcpdump, although the typical suspect would be name resolving.
>]Tip: Add your local machine name(s) into /etc/hosts.

>It does not help with ssh. ssh ALWAYS goes to the resolver.

Argh. Yes, you're right. And yes, it IS stupid. Well, at least for those
amongst us who hate to run a local DNS just because of such a silly
compile-time option (which - AFAIR - you can't even disable when
compiling it from the sources directly).

Michael
--
Michael Buchenrieder * (E-Mail Removed) * http://www.muc.de/~mibu
Lumber Cartel Unit #456 (TINLC) & Official Netscum
Note: If you want me to send you email, don't munge your address.