Discussion:
Setting up kppp for roaming account
(too old to reply)
Daniel
2006-12-17 02:48:11 UTC
Permalink
Dual Boot Win98 and Mandravis 2007 system. Posting this using my Win98
profile.

I'm away from home for a while, so I'm trying to set up kppp so it will
dial into my normal ISP so I can get my mail. Fortunately my ISP has a
portal or whatever you call it, so I'm not going to be paying long
distance 'phone rates.

When I dial in I get modem chatter for a couple of second then things go
quite (as I would expect) and the screen tells me it achieves connect
and starts pppd, but this final connection is never made. This is what
the kppp logfile looks like:-
Dec 17 13:24:41 localhost pppd[3152]: pppd 2.4.3 started by daniel, uid 500
Dec 17 13:24:41 localhost pppd[3152]: using channel 5
Dec 17 13:24:41 localhost pppd[3152]: Using interface ppp0
Dec 17 13:24:41 localhost pppd[3152]: Connect: ppp0 <--> /dev/ttyS0
Dec 17 13:24:41 localhost pppd[3152]: sent [LCP ConfReq id=0x1 <asyncmap 0xa0000> <magic 0x349a0dc7> <pcomp> <accomp>]
Dec 17 13:25:11 localhost pppd[3152]: LCP: timeout sending Config-Requests
Dec 17 13:25:11 localhost pppd[3152]: Connection terminated.
Dec 17 13:25:11 localhost pppd[3152]: using channel 6
Dec 17 13:25:11 localhost pppd[3152]: Using interface ppp0
Dec 17 13:25:11 localhost pppd[3152]: Connect: ppp0 <--> /dev/ttyS0
Dec 17 13:25:11 localhost pppd[3152]: sent [LCP ConfReq id=0x2 <asyncmap 0xa0000> <magic 0x5b62c3e3> <pcomp> <accomp>]
Dec 17 13:25:11 localhost pppd[3152]: tcflush failed: Bad file descriptor
Dec 17 13:25:11 localhost pppd[3152]: tcsetattr: Invalid argument (line 1025)
Dec 17 13:25:11 localhost pppd[3152]: Exit.
Does this give anybody any clues?

And originally the log was telling me I was using channels 1 & 2 but now
I'm using (or trying, at least) to use channels 5 & 6. Are these channel
numbers on the ISP's modem or something else??

TIA

Daniel
--
Posted via a free Usenet account from http://www.teranews.com
Unruh
2006-12-17 08:11:21 UTC
Permalink
Post by Daniel
Dual Boot Win98 and Mandravis 2007 system. Posting this using my Win98
profile.
I'm away from home for a while, so I'm trying to set up kppp so it will
dial into my normal ISP so I can get my mail. Fortunately my ISP has a
portal or whatever you call it, so I'm not going to be paying long
distance 'phone rates.
When I dial in I get modem chatter for a couple of second then things go
quite (as I would expect) and the screen tells me it achieves connect
and starts pppd, but this final connection is never made. This is what
the kppp logfile looks like:-
Dec 17 13:24:41 localhost pppd[3152]: pppd 2.4.3 started by daniel, uid 500
Dec 17 13:24:41 localhost pppd[3152]: using channel 5
Dec 17 13:24:41 localhost pppd[3152]: Using interface ppp0
Dec 17 13:24:41 localhost pppd[3152]: Connect: ppp0 <--> /dev/ttyS0
Dec 17 13:24:41 localhost pppd[3152]: sent [LCP ConfReq id=0x1 <asyncmap 0xa0000> <magic 0x349a0dc7> <pcomp> <accomp>]
Dec 17 13:25:11 localhost pppd[3152]: LCP: timeout sending Config-Requests
Put the line
daemon.*;local2.* /var/log/daemonlog
into /etc/sysconfig.conf and then run
killall -1 syslogd
Make sure you have the word
debug
in /etc/ppp/options


Try connecting again and then post the output. All of it.
Post by Daniel
Dec 17 13:25:11 localhost pppd[3152]: Connection terminated.
Dec 17 13:25:11 localhost pppd[3152]: using channel 6
Dec 17 13:25:11 localhost pppd[3152]: Using interface ppp0
Dec 17 13:25:11 localhost pppd[3152]: Connect: ppp0 <--> /dev/ttyS0
Dec 17 13:25:11 localhost pppd[3152]: sent [LCP ConfReq id=0x2 <asyncmap 0xa0000> <magic 0x5b62c3e3> <pcomp> <accomp>]
Dec 17 13:25:11 localhost pppd[3152]: tcflush failed: Bad file descriptor
Dec 17 13:25:11 localhost pppd[3152]: tcsetattr: Invalid argument (line 1025)
Dec 17 13:25:11 localhost pppd[3152]: Exit.
Does this give anybody any clues?
And originally the log was telling me I was using channels 1 & 2 but now
I'm using (or trying, at least) to use channels 5 & 6. Are these channel
numbers on the ISP's modem or something else??
TIA
Daniel
--
Posted via a free Usenet account from http://www.teranews.com
Moe Trin
2006-12-17 16:48:58 UTC
Permalink
On 17 Dec 2006, in the Usenet newsgroup comp.protocols.ppp, in article
Post by Unruh
Post by Daniel
When I dial in I get modem chatter for a couple of second then things go
quite (as I would expect) and the screen tells me it achieves connect
and starts pppd, but this final connection is never made.
Put the line
daemon.*;local2.* /var/log/daemonlog
Try connecting again and then post the output. All of it.
---------------------
Date: Fri, 15 Dec 2006 21:18:53 +1100
From: Daniel <***@nospam.albury.net.au>
Newsgroups: alt.os.linux.mandriva
Subject: Re: Setting up kppp
References: <45825589$0$15462$***@free.teranews.com>
Lines: 78
Message-ID: <458269db$0$15483$***@free.teranews.com>
NNTP-Posting-Date: 15 Dec 2006 09:24:45 GMT
---------------------

LCP negotiations - peer hard of hearing. Doesn't look to me to be an 'asyncmap'
(both proposing 0xa0000), or 'escape ff' problem. Peer never seems to notice
PAP AuthReq frame.

Old guy
Daniel
2006-12-18 05:42:51 UTC
Permalink
Post by Unruh
Post by Daniel
Dual Boot Win98 and Mandravis 2007 system. Posting this using my Win98
profile.
I'm away from home for a while, so I'm trying to set up kppp so it will
dial into my normal ISP so I can get my mail. Fortunately my ISP has a
portal or whatever you call it, so I'm not going to be paying long
distance 'phone rates.
When I dial in I get modem chatter for a couple of second then things go
quite (as I would expect) and the screen tells me it achieves connect
and starts pppd, but this final connection is never made. This is what
the kppp logfile looks like:-
Dec 17 13:24:41 localhost pppd[3152]: pppd 2.4.3 started by daniel, uid 500
Dec 17 13:24:41 localhost pppd[3152]: using channel 5
Dec 17 13:24:41 localhost pppd[3152]: Using interface ppp0
Dec 17 13:24:41 localhost pppd[3152]: Connect: ppp0 <--> /dev/ttyS0
Dec 17 13:24:41 localhost pppd[3152]: sent [LCP ConfReq id=0x1 <asyncmap 0xa0000> <magic 0x349a0dc7> <pcomp> <accomp>]
Dec 17 13:25:11 localhost pppd[3152]: LCP: timeout sending Config-Requests
Put the line
daemon.*;local2.* /var/log/daemonlog
into /etc/sysconfig.conf and then run
killall -1 syslogd
Make sure you have the word
debug
in /etc/ppp/options
Try connecting again and then post the output. All of it.
<snip>

Went looking for /etc/sysconfig.conf but could not find one, even as
root. Found a /etc/sysconfig/ if thats any help.

Can I just create a *.conf file and stick this line in? If so, is it
just a straight text file?

Daniel
--
Posted via a free Usenet account from http://www.teranews.com
Bit Twister
2006-12-18 05:50:48 UTC
Permalink
Post by Daniel
Went looking for /etc/sysconfig.conf but could not find one, even as
root. Found a /etc/sysconfig/ if thats any help.
On Mandriva Linux 2007 it is /etc/syslog.conf
Unruh
2006-12-18 22:27:10 UTC
Permalink
Post by Daniel
Post by Unruh
Post by Daniel
Dual Boot Win98 and Mandravis 2007 system. Posting this using my Win98
profile.
I'm away from home for a while, so I'm trying to set up kppp so it will
dial into my normal ISP so I can get my mail. Fortunately my ISP has a
portal or whatever you call it, so I'm not going to be paying long
distance 'phone rates.
When I dial in I get modem chatter for a couple of second then things go
quite (as I would expect) and the screen tells me it achieves connect
and starts pppd, but this final connection is never made. This is what
the kppp logfile looks like:-
Dec 17 13:24:41 localhost pppd[3152]: pppd 2.4.3 started by daniel, uid 500
Dec 17 13:24:41 localhost pppd[3152]: using channel 5
Dec 17 13:24:41 localhost pppd[3152]: Using interface ppp0
Dec 17 13:24:41 localhost pppd[3152]: Connect: ppp0 <--> /dev/ttyS0
Dec 17 13:24:41 localhost pppd[3152]: sent [LCP ConfReq id=0x1 <asyncmap 0xa0000> <magic 0x349a0dc7> <pcomp> <accomp>]
Dec 17 13:25:11 localhost pppd[3152]: LCP: timeout sending Config-Requests
Put the line
daemon.*;local2.* /var/log/daemonlog
into /etc/sysconfig.conf and then run
killall -1 syslogd
Make sure you have the word
debug
in /etc/ppp/options
Try connecting again and then post the output. All of it.
<snip>
Went looking for /etc/sysconfig.conf but could not find one, even as
root. Found a /etc/sysconfig/ if thats any help.
Sorry, misprint.
/etc/syslog.conf
Post by Daniel
Can I just create a *.conf file and stick this line in? If so, is it
just a straight text file?
Daniel
--
Posted via a free Usenet account from http://www.teranews.com
Daniel
2006-12-19 00:56:04 UTC
Permalink
Post by Unruh
Post by Daniel
Post by Unruh
Post by Daniel
Dual Boot Win98 and Mandravis 2007 system. Posting this using my Win98
profile.
I'm away from home for a while, so I'm trying to set up kppp so it will
dial into my normal ISP so I can get my mail. Fortunately my ISP has a
portal or whatever you call it, so I'm not going to be paying long
distance 'phone rates.
When I dial in I get modem chatter for a couple of second then things go
quite (as I would expect) and the screen tells me it achieves connect
and starts pppd, but this final connection is never made. This is what
the kppp logfile looks like:-
Dec 17 13:24:41 localhost pppd[3152]: pppd 2.4.3 started by daniel, uid 500
Dec 17 13:24:41 localhost pppd[3152]: using channel 5
Dec 17 13:24:41 localhost pppd[3152]: Using interface ppp0
Dec 17 13:24:41 localhost pppd[3152]: Connect: ppp0 <--> /dev/ttyS0
Dec 17 13:24:41 localhost pppd[3152]: sent [LCP ConfReq id=0x1 <asyncmap 0xa0000> <magic 0x349a0dc7> <pcomp> <accomp>]
Dec 17 13:25:11 localhost pppd[3152]: LCP: timeout sending Config-Requests
Put the line
daemon.*;local2.* /var/log/daemonlog
into /etc/sysconfig.conf and then run
killall -1 syslogd
Make sure you have the word
debug
in /etc/ppp/options
Try connecting again and then post the output. All of it.
<snip>
Went looking for /etc/sysconfig.conf but could not find one, even as
root. Found a /etc/sysconfig/ if thats any help.
Sorry, misprint.
/etc/syslog.conf
Post by Daniel
Can I just create a *.conf file and stick this line in? If so, is it
just a straight text file?
Daniel
--
Posted via a free Usenet account from http://www.teranews.com
O.K. Made the addition to etc/syslog.conf, then killall -1 syslogd (is
this a just noticed mis-typing of syslog* or similar??) and started kppp
which produced this daemenlog:-

Dec 19 11:29:32 localhost pppd[3684]: Can't open options file
/etc/ppp/options: Permission denied
Dec 19 11:30:00 localhost pppd[3685]: pppd 2.4.3 started by daniel, uid 500
Dec 19 11:30:00 localhost pppd[3685]: using channel 1
Dec 19 11:30:00 localhost pppd[3685]: Using interface ppp0
Dec 19 11:30:00 localhost pppd[3685]: Connect: ppp0 <--> /dev/ttyS0
Dec 19 11:30:00 localhost pppd[3685]: sent [LCP ConfReq id=0x1 <asyncmap
0x0> <magic 0x6d4aa063> <pcomp> <accomp>]
Dec 19 11:30:00 localhost pppd[3685]: rcvd [LCP ConfReq id=0x1 < 00 04
00 00> <mru 1524> <asyncmap 0xa0000> <auth pap> <pcomp> <accomp> <mrru
1524> <endpoint [local:73.74.61.63.6b]> < 17 04 44 03>]
Dec 19 11:30:00 localhost pppd[3685]: sent [LCP ConfRej id=0x1 < 00 04
00 00> <mrru 1524> < 17 04 44 03>]
Dec 19 11:30:00 localhost pppd[3685]: rcvd [LCP ConfAck id=0x1 <asyncmap
0x0> <magic 0x6d4aa063> <pcomp> <accomp>]
Dec 19 11:30:00 localhost pppd[3685]: rcvd [LCP ConfReq id=0x2 <mru
1524> <asyncmap 0xa0000> <auth pap> <pcomp> <accomp> <endpoint
[local:73.74.61.63.6b]>]
Dec 19 11:30:00 localhost pppd[3685]: sent [LCP ConfAck id=0x2 <mru
1524> <asyncmap 0xa0000> <auth pap> <pcomp> <accomp> <endpoint
[local:73.74.61.63.6b]>]
Dec 19 11:30:00 localhost pppd[3685]: sent [PAP AuthReq id=0x1
user="***@roam.albury.net.au" password=<hidden>]
Dec 19 11:30:01 localhost pppd[3685]: rcvd [LCP ConfReq id=0x1 <asyncmap
0xa0000> <auth pap> <magic 0x9bfcaa13> <pcomp> <accomp> <mrru 1524>
<endpoint [local:61.61.70.74.76.69.63]>]
Dec 19 11:30:01 localhost pppd[3685]: sent [LCP ConfReq id=0x2 <asyncmap
0x0> <magic 0x9219584f> <pcomp> <accomp>]
Dec 19 11:30:01 localhost pppd[3685]: sent [LCP ConfRej id=0x1 <mrru 1524>]
Dec 19 11:30:01 localhost pppd[3685]: rcvd [LCP ConfAck id=0x2 <asyncmap
0x0> <magic 0x9219584f> <pcomp> <accomp>]
Dec 19 11:30:01 localhost pppd[3685]: rcvd [LCP ConfReq id=0x2 <asyncmap
0xa0000> <auth pap> <magic 0x9bfcaa13> <pcomp> <accomp> <endpoint
[local:61.61.70.74.76.69.63]>]
Dec 19 11:30:01 localhost pppd[3685]: sent [LCP ConfAck id=0x2 <asyncmap
0xa0000> <auth pap> <magic 0x9bfcaa13> <pcomp> <accomp> <endpoint
[local:61.61.70.74.76.69.63]>]
Dec 19 11:30:01 localhost pppd[3685]: sent [PAP AuthReq id=0x2
user="***@roam.albury.net.au" password=<hidden>]
Dec 19 11:30:02 localhost pppd[3685]: rcvd [LCP ConfReq id=0x52 <mru
1456> <asyncmap 0xa0000> <auth pap> <magic 0x9bfcaa13>]
Dec 19 11:30:02 localhost pppd[3685]: sent [LCP ConfReq id=0x3 <asyncmap
0x0> <magic 0xdc55ebd4> <pcomp> <accomp>]
Dec 19 11:30:02 localhost pppd[3685]: sent [LCP ConfAck id=0x52 <mru
1456> <asyncmap 0xa0000> <auth pap> <magic 0x9bfcaa13>]
Dec 19 11:30:02 localhost pppd[3685]: rcvd [LCP ConfRej id=0x3 <asyncmap
0x0> <pcomp> <accomp>]
Dec 19 11:30:02 localhost pppd[3685]: sent [LCP ConfReq id=0x4 <magic
0xdc55ebd4>]
Dec 19 11:30:02 localhost pppd[3685]: rcvd [LCP ConfAck id=0x4 <magic
0xdc55ebd4>]
Dec 19 11:30:02 localhost pppd[3685]: sent [PAP AuthReq id=0x3
user="***@roam.albury.net.au" password=<hidden>]
Dec 19 11:30:05 localhost pppd[3685]: sent [PAP AuthReq id=0x4
user="***@roam.albury.net.au" password=<hidden>]
Dec 19 11:30:08 localhost pppd[3685]: sent [PAP AuthReq id=0x5
user="***@roam.albury.net.au" password=<hidden>]
Dec 19 11:30:11 localhost pppd[3685]: sent [PAP AuthReq id=0x6
user="***@roam.albury.net.au" password=<hidden>]
Dec 19 11:30:14 localhost pppd[3685]: sent [PAP AuthReq id=0x7
user="***@roam.albury.net.au" password=<hidden>]
Dec 19 11:30:17 localhost pppd[3685]: sent [PAP AuthReq id=0x8
user="***@roam.albury.net.au" password=<hidden>]
Dec 19 11:30:20 localhost pppd[3685]: sent [PAP AuthReq id=0x9
user="***@roam.albury.net.au" password=<hidden>]
Dec 19 11:30:23 localhost pppd[3685]: sent [PAP AuthReq id=0xa
user="***@roam.albury.net.au" password=<hidden>]
Dec 19 11:30:26 localhost pppd[3685]: sent [PAP AuthReq id=0xb
user="***@roam.albury.net.au" password=<hidden>]
Dec 19 11:30:29 localhost pppd[3685]: sent [PAP AuthReq id=0xc
user="***@roam.albury.net.au" password=<hidden>]
Dec 19 11:30:32 localhost pppd[3685]: No response to PAP
authenticate-requests
Dec 19 11:30:32 localhost pppd[3685]: sent [LCP TermReq id=0x5 "Failed
to authenticate ourselves to peer"]
Dec 19 11:30:32 localhost pppd[3685]: rcvd [LCP TermAck id=0x5]
Dec 19 11:30:32 localhost pppd[3685]: Connection terminated.
Dec 19 11:30:32 localhost pppd[3685]: Exit.

Just looking at this last section, seems to indicate that I shouldn't be
using ***@roam.albury.net.au as the instructions from my ISP state. I
haven't tried just "dxmm". Should I give it a go.....or does the rest of
the log give other clues??

TIA

Daniel
--
Posted via a free Usenet account from http://www.teranews.com
Clifford Kite
2006-12-19 03:53:24 UTC
Permalink
Post by Daniel
Post by Unruh
Put the line
daemon.*;local2.* /var/log/daemonlog
into /etc/sysconfig.conf and then run
killall -1 syslogd
Make sure you have the word
debug
in /etc/ppp/options
Try connecting again and then post the output. All of it.
O.K. Made the addition to etc/syslog.conf, then killall -1 syslogd (is
this a just noticed mis-typing of syslog* or similar??) and started kppp
which produced this daemenlog:-
Dec 19 11:29:32 localhost pppd[3684]: Can't open options file
/etc/ppp/options: Permission denied
Dec 19 11:30:00 localhost pppd[3685]: pppd 2.4.3 started by daniel, uid 500
Dec 19 11:30:00 localhost pppd[3685]: using channel 1
Dec 19 11:30:00 localhost pppd[3685]: Using interface ppp0
Dec 19 11:30:00 localhost pppd[3685]: Connect: ppp0 <--> /dev/ttyS0
Dec 19 11:30:00 localhost pppd[3685]: sent [LCP ConfReq id=0x1 <asyncmap
0x0> <magic 0x6d4aa063> <pcomp> <accomp>]
Pppd sends an LCP request with no asyncmap specified.
Post by Daniel
Dec 19 11:30:00 localhost pppd[3685]: rcvd [LCP ConfReq id=0x1 < 00 04
00 00> <mru 1524> <asyncmap 0xa0000> <auth pap> <pcomp> <accomp> <mrru
Pppd receives a request with asyncmap a0000 specified.
Post by Daniel
1524> <endpoint [local:73.74.61.63.6b]> < 17 04 44 03>]
Dec 19 11:30:00 localhost pppd[3685]: sent [LCP ConfRej id=0x1 < 00 04
00 00> <mrru 1524> < 17 04 44 03>]
Dec 19 11:30:00 localhost pppd[3685]: rcvd [LCP ConfAck id=0x1 <asyncmap
0x0> <magic 0x6d4aa063> <pcomp> <accomp>]
Dec 19 11:30:00 localhost pppd[3685]: rcvd [LCP ConfReq id=0x2 <mru
1524> <asyncmap 0xa0000> <auth pap> <pcomp> <accomp> <endpoint
[local:73.74.61.63.6b]>]
Dec 19 11:30:00 localhost pppd[3685]: sent [LCP ConfAck id=0x2 <mru
1524> <asyncmap 0xa0000> <auth pap> <pcomp> <accomp> <endpoint
[local:73.74.61.63.6b]>]
Dec 19 11:30:00 localhost pppd[3685]: sent [PAP AuthReq id=0x1
Pppd sends a PAP AuthReq with presumably appropriate information and
the negotiations promptly break down.
Post by Daniel
Dec 19 11:30:01 localhost pppd[3685]: rcvd [LCP ConfReq id=0x1 <asyncmap
0xa0000> <auth pap> <magic 0x9bfcaa13> <pcomp> <accomp> <mrru 1524>
<endpoint [local:61.61.70.74.76.69.63]>]
The peer restarts LCP negotiation.

It's a well-known problem to most regulars here, namely that pppd
*must* be configured with the option "asyncmap a0000" (or with an
escape option even more liberal) to accommodate the peer's broken
PPP implementation. You need to find out how to do that with kppp,
or perhaps do "chmod 644 /etc/ppp/options" and put it there.

In way of explanation, all characters less than 20h are escaped by
pppd prior to LCP entering the Open state but only those specified by
an escape option thereafter, which is RFC correct. But the broken
peer isn't prepared to receive an unescaped character with hexadecimal
representation 11h or 13h, corresponding to a0000, so negotiation
breaks down.
--
Clifford Kite
/* Speak softly and carry a +6 two-handed sword. */
Clifford Kite
2006-12-19 04:00:38 UTC
Permalink
Post by Clifford Kite
Post by Daniel
Dec 19 11:30:00 localhost pppd[3685]: sent [LCP ConfReq id=0x1 <asyncmap
0x0> <magic 0x6d4aa063> <pcomp> <accomp>]
Pppd sends an LCP request with no asyncmap specified.
Duhh! Make that with asyncmap 00 specified.
--
Clifford Kite
Daniel
2006-12-19 11:20:10 UTC
Permalink
Post by Clifford Kite
Post by Clifford Kite
Post by Daniel
Dec 19 11:30:00 localhost pppd[3685]: sent [LCP ConfReq id=0x1 <asyncmap
0x0> <magic 0x6d4aa063> <pcomp> <accomp>]
Pppd sends an LCP request with no asyncmap specified.
Duhh! Make that with asyncmap 00 specified.
O.K., I'll see if I can set asyncmap to a000 and get back to you in the
morning.

Daniel
--
Posted via a free Usenet account from http://www.teranews.com
Clifford Kite
2006-12-19 16:43:59 UTC
Permalink
Post by Daniel
Post by Clifford Kite
Post by Clifford Kite
Pppd sends an LCP request with no asyncmap specified.
Duhh! Make that with asyncmap 00 specified.
O.K., I'll see if I can set asyncmap to a000 and get back to you in the
morning. ^^^^
\
It seems that we are plagued by "mis-prints," that should be a0000 .
BTW, "asyncmap 00" is the pppd implementation default, so it's not
likely to be found anywhere in the kppp configuration.
--
Clifford Kite
/* Better is the enemy of good enough. */
Unruh
2006-12-19 23:16:00 UTC
Permalink
Post by Daniel
Post by Clifford Kite
Post by Clifford Kite
Post by Daniel
Dec 19 11:30:00 localhost pppd[3685]: sent [LCP ConfReq id=0x1 <asyncmap
0x0> <magic 0x6d4aa063> <pcomp> <accomp>]
Pppd sends an LCP request with no asyncmap specified.
Duhh! Make that with asyncmap 00 specified.
O.K., I'll see if I can set asyncmap to a000 and get back to you in the
morning.
No. a0000

Critical to get it right.
Moe Trin
2006-12-19 19:57:02 UTC
Permalink
On Mon, 18 Dec 2006, in the Usenet newsgroup comp.protocols.ppp, in article
<***@corncob.inetport.tld>, Clifford Kite wrote:

Happy Holidays, Clifford!
Post by Clifford Kite
Pppd sends a PAP AuthReq with presumably appropriate information and
the negotiations promptly break down.
The O/P had posted a similar log to 'alt.os.linux.mandriva' on Friday
with near identical results. (Message-ID:
<458269db$0$15483$***@free.teranews.com> dated 15 Dec 2006 21:18:53
+1100).
Post by Clifford Kite
Post by Daniel
Dec 19 11:30:01 localhost pppd[3685]: rcvd [LCP ConfReq id=0x1 <asyncmap
0xa0000> <auth pap> <magic 0x9bfcaa13> <pcomp> <accomp> <mrru 1524>
<endpoint [local:61.61.70.74.76.69.63]>]
The peer restarts LCP negotiation.
which it also did in his Friday post. The difference is
Post by Clifford Kite
It's a well-known problem to most regulars here, namely that pppd
*must* be configured with the option "asyncmap a0000" (or with an
escape option even more liberal) to accommodate the peer's broken
PPP implementation.
in that log, it showed his system proposing 0xa0000 to the peer initially.

-------------
Dec 15 20:54:39 localhost pppd[2919]: sent [LCP ConfReq id=0x1 <asyncmap
0xa0000> <magic 0xf735e260> <pcomp> <accomp>]
Dec 15 20:54:39 localhost pppd[2919]: rcvd [LCP ConfReq id=0x1 < 00 04 00
00><mru 1524> <asyncmap 0xa0000> <auth pap> <pcomp> <accomp> <mrru 1524>
<endpoint [local :73.74.61.63.6b]> < 17 04 33 06>]
Dec 15 20:54:39 localhost pppd[2919]: sent [LCP ConfRej id=0x1 < 00 04 00
00> <mrru 1524> < 17 04 33 06>]
Dec 15 20:54:39 localhost pppd[2919]: rcvd [LCP ConfAck id=0x1 <asyncmap
0xa0000> <magic 0xf735e260> <pcomp> <accomp>]
Dec 15 20:54:40 localhost pppd[2919]: rcvd [LCP ConfReq id=0x2 <mru 1524>
<asyncmap 0xa0000> <auth pap> <pcomp> <accomp> <endpoint
[local:73.74.61.63.6b]>]
Dec 15 20:54:40 localhost pppd[2919]: sent [LCP ConfAck id=0x2 <mru 1524>
<asyncmap 0xa0000> <auth pap> <pcomp> <accomp> <endpoint
[local:73.74.61.63.6b]>]
Dec 15 20:54:40 localhost pppd[2919]: sent [PAP AuthReq id=0x1 user="dxmm"
password=<hidden>]
Dec 15 20:54:40 localhost pppd[2919]: rcvd [LCP ConfReq id=0x1 <asyncmap
0xa0000> <auth pap> <magic 0x3c747bd6> <pcomp> <accomp> <mrru 1524>
<endpoint [local:61.61.70.74.76.69.63]>]
-------------
Post by Clifford Kite
In way of explanation, all characters less than 20h are escaped by
pppd prior to LCP entering the Open state but only those specified by
an escape option thereafter, which is RFC correct. But the broken
peer isn't prepared to receive an unescaped character with hexadecimal
representation 11h or 13h, corresponding to a0000, so negotiation
breaks down.
OK, I think. One other item in the other log showed the peer with a
rather confused sequence number and different options after the second
'PAP AuthReq' attempt:

-------------
Dec 15 20:54:40 localhost pppd[2919]: sent [PAP AuthReq id=0x2 user="dxmm"
password=<hidden>]
Dec 15 20:54:41 localhost pppd[2919]: rcvd [LCP ConfReq id=0xdf <mru 1456>
<asyncmap 0xa0000> <auth pap> <magic 0x3c747bd6>]
Dec 15 20:54:41 localhost pppd[2919]: sent [LCP ConfReq id=0x3 <asyncmap
0xa0000> <magic 0x4147de99> <pcomp> <accomp>]
Dec 15 20:54:41 localhost pppd[2919]: sent [LCP ConfAck id=0xdf <mru 1456>
<asyncmap 0xa0000> <auth pap> <magic 0x3c747bd6>]
Dec 15 20:54:41 localhost pppd[2919]: rcvd [LCP ConfRej id=0x3 <asyncmap
0xa0000> <pcomp> <accomp>]
-------------

Left me confused - never mind his system ;-) So are you saying that
'escape 0xff' (or 'escape ff' - the man page description hasn't changed
since at least 2.1.2d) should fix this?

Old guy
Clifford Kite
2006-12-20 03:39:19 UTC
Permalink
Post by Moe Trin
On Mon, 18 Dec 2006, in the Usenet newsgroup comp.protocols.ppp, in article
Happy Holidays, Clifford!
Back at you! To quote a SG1 character.
Post by Moe Trin
Post by Clifford Kite
Pppd sends a PAP AuthReq with presumably appropriate information and
the negotiations promptly break down.
The O/P had posted a similar log to 'alt.os.linux.mandriva' on Friday
+1100).
Post by Clifford Kite
Post by Daniel
Dec 19 11:30:01 localhost pppd[3685]: rcvd [LCP ConfReq id=0x1 <asyncmap
0xa0000> <auth pap> <magic 0x9bfcaa13> <pcomp> <accomp> <mrru 1524>
<endpoint [local:61.61.70.74.76.69.63]>]
The peer restarts LCP negotiation.
which it also did in his Friday post. The difference is
Post by Clifford Kite
It's a well-known problem to most regulars here, namely that pppd
*must* be configured with the option "asyncmap a0000" (or with an
escape option even more liberal) to accommodate the peer's broken
PPP implementation.
in that log, it showed his system proposing 0xa0000 to the peer initially.
-------------
Dec 15 20:54:39 localhost pppd[2919]: sent [LCP ConfReq id=0x1 <asyncmap
0xa0000> <magic 0xf735e260> <pcomp> <accomp>]
Yes...
Post by Moe Trin
Dec 15 20:54:39 localhost pppd[2919]: rcvd [LCP ConfReq id=0x1 < 00 04 00
00><mru 1524> <asyncmap 0xa0000> <auth pap> <pcomp> <accomp> <mrru 1524>
<endpoint [local :73.74.61.63.6b]> < 17 04 33 06>]
Dec 15 20:54:39 localhost pppd[2919]: sent [LCP ConfRej id=0x1 < 00 04 00
00> <mrru 1524> < 17 04 33 06>]
Dec 15 20:54:39 localhost pppd[2919]: rcvd [LCP ConfAck id=0x1 <asyncmap
0xa0000> <magic 0xf735e260> <pcomp> <accomp>]
Dec 15 20:54:40 localhost pppd[2919]: rcvd [LCP ConfReq id=0x2 <mru 1524>
<asyncmap 0xa0000> <auth pap> <pcomp> <accomp> <endpoint
[local:73.74.61.63.6b]>]
Dec 15 20:54:40 localhost pppd[2919]: sent [LCP ConfAck id=0x2 <mru 1524>
<asyncmap 0xa0000> <auth pap> <pcomp> <accomp> <endpoint
[local:73.74.61.63.6b]>]
Dec 15 20:54:40 localhost pppd[2919]: sent [PAP AuthReq id=0x1 user="dxmm"
password=<hidden>]
Dec 15 20:54:40 localhost pppd[2919]: rcvd [LCP ConfReq id=0x1 <asyncmap
0xa0000> <auth pap> <magic 0x3c747bd6> <pcomp> <accomp> <mrru 1524>
<endpoint [local:61.61.70.74.76.69.63]>]
And here the peer seems not to have received pppd's "LCP ConfAck id=0x2"
since it ignores the "PAP AuthReq" and repeats it's first "LCP ConfReq
id=0x1" request but drops only 2 of the 3 rejected options -and- includes
a magic number. It may be legal but it's weird.
Post by Moe Trin
-------------
Post by Clifford Kite
In way of explanation, all characters less than 20h are escaped by
pppd prior to LCP entering the Open state but only those specified by
an escape option thereafter, which is RFC correct. But the broken
peer isn't prepared to receive an unescaped character with hexadecimal
representation 11h or 13h, corresponding to a0000, so negotiation
breaks down.
OK, I think. One other item in the other log showed the peer with a
rather confused sequence number and different options after the second
-------------
Dec 15 20:54:40 localhost pppd[2919]: sent [PAP AuthReq id=0x2 user="dxmm"
password=<hidden>]
Dec 15 20:54:41 localhost pppd[2919]: rcvd [LCP ConfReq id=0xdf <mru 1456>
<asyncmap 0xa0000> <auth pap> <magic 0x3c747bd6>]
An id number jump doesn't bother me since I don't think they need to
be sequential.
Post by Moe Trin
Dec 15 20:54:41 localhost pppd[2919]: sent [LCP ConfReq id=0x3 <asyncmap
0xa0000> <magic 0x4147de99> <pcomp> <accomp>]
Dec 15 20:54:41 localhost pppd[2919]: sent [LCP ConfAck id=0xdf <mru 1456>
<asyncmap 0xa0000> <auth pap> <magic 0x3c747bd6>]
The id of a LCP Conf{Ack,Nak,Rej} need only match that of the last
ConfReq, as the ConfAck above does. RFC 1661, "5. LCP Packet Formats."
Post by Moe Trin
Dec 15 20:54:41 localhost pppd[2919]: rcvd [LCP ConfRej id=0x3 <asyncmap
0xa0000> <pcomp> <accomp>]
-------------
Why the peer sends a LCP ConfRej for all requested options is beyond me.
Post by Moe Trin
Left me confused - never mind his system ;-) So are you saying that
'escape 0xff' (or 'escape ff' - the man page description hasn't changed
since at least 2.1.2d) should fix this?
No, I thought "asyncmap a0000" would cure what I read into the log
posted here. It seemed like, and even now still seems like, an ACCM
(Asynchronous Control Character Map - asyncmap) problem. The OP can
try adding the pppd option "default-asyncmap" - the PPP default ACCM,
escaping all CCs - and if that allows authentication to proceed then
the peer was probably still expecting escaped characters while pppd had
begun using the ACCM because it had both received and sent an LCP ConfAck.
If so then pppd may have begun sending unescaped characters before "all
pending output" (read, before the ConfAck which was sent just prior to
sending the PAP AuthReq above) was sent, contrary to the recommendation
in a certain book about PPP.

If that doesn't work then maybe either the username or password needed
by the "portal" differs from the one for the ISP at home, although the
peer should Nak an invalid AuthReq and follow the Nak with a TermReq,
not ignore it and restart LCP requests - unless the peer deems LCP not
to be Open when it receives the AuthReq.

(The "escape xx,yy,..." is for escaping selected characters sent
to the peer regardless of whether the peer included them it's ACCM
request or not. A PPP implementation MUST be able to receive escaped
characters at any time; paragraph 4 under "4.2. Transparency," RFC
1662. Otherwise it graduates from buggy to horribly non-compliant.)
--
Clifford Kite
/* The generation of random numbers is too important to be left
to chance. */
Moe Trin
2006-12-21 00:38:32 UTC
Permalink
On Tue, 19 Dec 2006, in the Usenet newsgroup comp.protocols.ppp, in article
Post by Clifford Kite
And here the peer seems not to have received pppd's "LCP ConfAck id=0x2"
since it ignores the "PAP AuthReq" and repeats it's first "LCP ConfReq
id=0x1" request but drops only 2 of the 3 rejected options -and- includes
a magic number. It may be legal but it's weird.
Well, I know that computers don't do things arbitrarily, but this really
is confusing. I was wondering if it didn't have anything to do with the
BACP, or vendor specific options. Certainly the peer seems to have no
problem hearing the initial exchange.
Post by Clifford Kite
An id number jump doesn't bother me since I don't think they need to
be sequential.
RFC1661 section 5 doesn't seem to say anything on this - my take is that
the number need only be unique. However I also can't see any reason for
the numbers to be random - if anything, this would complicate the code.
Sequential numbers - I don't care if they go up, down, or sideways - are
just easier to generate while remaining unique. I know, I know - where
does logic come into implementations, much less specifications.
Post by Clifford Kite
No, I thought "asyncmap a0000" would cure what I read into the log
posted here. It seemed like, and even now still seems like, an ACCM
(Asynchronous Control Character Map - asyncmap) problem.
Agreed - that was my first reaction on Friday.
Post by Clifford Kite
The OP can try adding the pppd option "default-asyncmap" - the PPP
default ACCM, escaping all CCs - and if that allows authentication to
proceed then the peer was probably still expecting escaped characters
while pppd had begun using the ACCM because it had both received and
sent an LCP ConfAck. If so then pppd may have begun sending unescaped
characters before "all pending output" (read, before the ConfAck which
was sent just prior to sending the PAP AuthReq above) was sent, contrary
to the recommendation in a certain book about PPP.
I've really got to get a copy of that.
Post by Clifford Kite
If that doesn't work then maybe either the username or password needed
by the "portal" differs from the one for the ISP at home, although the
peer should Nak an invalid AuthReq and follow the Nak with a TermReq,
not ignore it and restart LCP requests - unless the peer deems LCP not
to be Open when it receives the AuthReq.
My take on this is that the O/P is able to connect using windoze (though
at this point, I can't say where I saw that), and I'd expect him to be
aware of any difference in login.
Post by Clifford Kite
(The "escape xx,yy,..." is for escaping selected characters sent
to the peer regardless of whether the peer included them it's ACCM
request or not.
Ahhh, OK.
Post by Clifford Kite
A PPP implementation MUST be able to receive escaped characters at any
time; paragraph 4 under "4.2. Transparency," RFC 1662. Otherwise it
graduates from buggy to horribly non-compliant.)
and I think we've seen a few of those before.

Old guy
Unruh
2006-12-19 23:14:43 UTC
Permalink
Post by Daniel
Post by Unruh
Post by Daniel
Post by Unruh
Post by Daniel
Dual Boot Win98 and Mandravis 2007 system. Posting this using my Win98
profile.
I'm away from home for a while, so I'm trying to set up kppp so it will
dial into my normal ISP so I can get my mail. Fortunately my ISP has a
portal or whatever you call it, so I'm not going to be paying long
distance 'phone rates.
When I dial in I get modem chatter for a couple of second then things go
quite (as I would expect) and the screen tells me it achieves connect
and starts pppd, but this final connection is never made. This is what
the kppp logfile looks like:-
Dec 17 13:24:41 localhost pppd[3152]: pppd 2.4.3 started by daniel, uid 500
Dec 17 13:24:41 localhost pppd[3152]: using channel 5
Dec 17 13:24:41 localhost pppd[3152]: Using interface ppp0
Dec 17 13:24:41 localhost pppd[3152]: Connect: ppp0 <--> /dev/ttyS0
Dec 17 13:24:41 localhost pppd[3152]: sent [LCP ConfReq id=0x1 <asyncmap 0xa0000> <magic 0x349a0dc7> <pcomp> <accomp>]
Dec 17 13:25:11 localhost pppd[3152]: LCP: timeout sending Config-Requests
Put the line
daemon.*;local2.* /var/log/daemonlog
into /etc/sysconfig.conf and then run
killall -1 syslogd
Make sure you have the word
debug
in /etc/ppp/options
Try connecting again and then post the output. All of it.
<snip>
Went looking for /etc/sysconfig.conf but could not find one, even as
root. Found a /etc/sysconfig/ if thats any help.
Sorry, misprint.
/etc/syslog.conf
Post by Daniel
Can I just create a *.conf file and stick this line in? If so, is it
just a straight text file?
Daniel
--
Posted via a free Usenet account from http://www.teranews.com
O.K. Made the addition to etc/syslog.conf, then killall -1 syslogd (is
this a just noticed mis-typing of syslog* or similar??) and started kppp
which produced this daemenlog:-
Dec 19 11:29:32 localhost pppd[3684]: Can't open options file
/etc/ppp/options: Permission denied
Dec 19 11:30:00 localhost pppd[3685]: pppd 2.4.3 started by daniel, uid 500
Dec 19 11:30:00 localhost pppd[3685]: using channel 1
Dec 19 11:30:00 localhost pppd[3685]: Using interface ppp0
Dec 19 11:30:00 localhost pppd[3685]: Connect: ppp0 <--> /dev/ttyS0
Dec 19 11:30:00 localhost pppd[3685]: sent [LCP ConfReq id=0x1 <asyncmap
0x0> <magic 0x6d4aa063> <pcomp> <accomp>]
Dec 19 11:30:00 localhost pppd[3685]: rcvd [LCP ConfReq id=0x1 < 00 04
00 00> <mru 1524> <asyncmap 0xa0000> <auth pap> <pcomp> <accomp> <mrru
1524> <endpoint [local:73.74.61.63.6b]> < 17 04 44 03>]
Dec 19 11:30:00 localhost pppd[3685]: sent [LCP ConfRej id=0x1 < 00 04
00 00> <mrru 1524> < 17 04 44 03>]
Dec 19 11:30:00 localhost pppd[3685]: rcvd [LCP ConfAck id=0x1 <asyncmap
0x0> <magic 0x6d4aa063> <pcomp> <accomp>]
Dec 19 11:30:00 localhost pppd[3685]: rcvd [LCP ConfReq id=0x2 <mru
1524> <asyncmap 0xa0000> <auth pap> <pcomp> <accomp> <endpoint
[local:73.74.61.63.6b]>]
Dec 19 11:30:00 localhost pppd[3685]: sent [LCP ConfAck id=0x2 <mru
1524> <asyncmap 0xa0000> <auth pap> <pcomp> <accomp> <endpoint
[local:73.74.61.63.6b]>]
Dec 19 11:30:00 localhost pppd[3685]: sent [PAP AuthReq id=0x1
Dec 19 11:30:01 localhost pppd[3685]: rcvd [LCP ConfReq id=0x1 <asyncmap
0xa0000> <auth pap> <magic 0x9bfcaa13> <pcomp> <accomp> <mrru 1524>
<endpoint [local:61.61.70.74.76.69.63]>]
Dec 19 11:30:01 localhost pppd[3685]: sent [LCP ConfReq id=0x2 <asyncmap
0x0> <magic 0x9219584f> <pcomp> <accomp>]
Dec 19 11:30:01 localhost pppd[3685]: sent [LCP ConfRej id=0x1 <mrru 1524>]
Dec 19 11:30:01 localhost pppd[3685]: rcvd [LCP ConfAck id=0x2 <asyncmap
0x0> <magic 0x9219584f> <pcomp> <accomp>]
Dec 19 11:30:01 localhost pppd[3685]: rcvd [LCP ConfReq id=0x2 <asyncmap
0xa0000> <auth pap> <magic 0x9bfcaa13> <pcomp> <accomp> <endpoint
[local:61.61.70.74.76.69.63]>]
Dec 19 11:30:01 localhost pppd[3685]: sent [LCP ConfAck id=0x2 <asyncmap
0xa0000> <auth pap> <magic 0x9bfcaa13> <pcomp> <accomp> <endpoint
[local:61.61.70.74.76.69.63]>]
Dec 19 11:30:01 localhost pppd[3685]: sent [PAP AuthReq id=0x2
Dec 19 11:30:02 localhost pppd[3685]: rcvd [LCP ConfReq id=0x52 <mru
1456> <asyncmap 0xa0000> <auth pap> <magic 0x9bfcaa13>]
Dec 19 11:30:02 localhost pppd[3685]: sent [LCP ConfReq id=0x3 <asyncmap
0x0> <magic 0xdc55ebd4> <pcomp> <accomp>]
Dec 19 11:30:02 localhost pppd[3685]: sent [LCP ConfAck id=0x52 <mru
1456> <asyncmap 0xa0000> <auth pap> <magic 0x9bfcaa13>]
Dec 19 11:30:02 localhost pppd[3685]: rcvd [LCP ConfRej id=0x3 <asyncmap
0x0> <pcomp> <accomp>]
Dec 19 11:30:02 localhost pppd[3685]: sent [LCP ConfReq id=0x4 <magic
0xdc55ebd4>]
Dec 19 11:30:02 localhost pppd[3685]: rcvd [LCP ConfAck id=0x4 <magic
0xdc55ebd4>]
Dec 19 11:30:02 localhost pppd[3685]: sent [PAP AuthReq id=0x3
Dec 19 11:30:05 localhost pppd[3685]: sent [PAP AuthReq id=0x4
Dec 19 11:30:08 localhost pppd[3685]: sent [PAP AuthReq id=0x5
Dec 19 11:30:11 localhost pppd[3685]: sent [PAP AuthReq id=0x6
Dec 19 11:30:14 localhost pppd[3685]: sent [PAP AuthReq id=0x7
Dec 19 11:30:17 localhost pppd[3685]: sent [PAP AuthReq id=0x8
Dec 19 11:30:20 localhost pppd[3685]: sent [PAP AuthReq id=0x9
Dec 19 11:30:23 localhost pppd[3685]: sent [PAP AuthReq id=0xa
Dec 19 11:30:26 localhost pppd[3685]: sent [PAP AuthReq id=0xb
Dec 19 11:30:29 localhost pppd[3685]: sent [PAP AuthReq id=0xc
Dec 19 11:30:32 localhost pppd[3685]: No response to PAP
authenticate-requests
Dec 19 11:30:32 localhost pppd[3685]: sent [LCP TermReq id=0x5 "Failed
to authenticate ourselves to peer"]
Dec 19 11:30:32 localhost pppd[3685]: rcvd [LCP TermAck id=0x5]
Dec 19 11:30:32 localhost pppd[3685]: Connection terminated.
Dec 19 11:30:32 localhost pppd[3685]: Exit.
OK,
as root do
chmod +s /usr/bin/ppp


Also the far side is having trouble hearing you.
Try putting into /etc/ppp/options
asyncmap 0xa0000

The far end is a broken windows system.
Post by Daniel
Just looking at this last section, seems to indicate that I shouldn't be
haven't tried just "dxmm". Should I give it a go.....or does the rest of
the log give other clues??
Nope just stupidity from your ISP. And incompetence.

for more help try using
www.theory.physics.ubc.ca/ppp-linux.html
Clifford Kite
2006-12-18 17:35:50 UTC
Permalink
Post by Daniel
Dual Boot Win98 and Mandravis 2007 system. Posting this using my Win98
profile.
Probably using the winmodem on the Linux side too.
Post by Daniel
I'm away from home for a while, so I'm trying to set up kppp so it will
dial into my normal ISP so I can get my mail. Fortunately my ISP has a
portal or whatever you call it, so I'm not going to be paying long
distance 'phone rates.
It's called a POP, Point of Presence, in U.S.
Post by Daniel
When I dial in I get modem chatter for a couple of second then things go
quite (as I would expect) and the screen tells me it achieves connect
and starts pppd, but this final connection is never made. This is what
the kppp logfile looks like:-
I'd also expect quiet when the modem negotiation fails or the other end
hangs up, and kppp doesn't detect it.
Post by Daniel
Dec 17 13:24:41 localhost pppd[3152]: pppd 2.4.3 started by daniel, uid 500
Dec 17 13:24:41 localhost pppd[3152]: using channel 5
Dec 17 13:24:41 localhost pppd[3152]: Using interface ppp0
Dec 17 13:24:41 localhost pppd[3152]: Connect: ppp0 <--> /dev/ttyS0
Dec 17 13:24:41 localhost pppd[3152]: sent [LCP ConfReq id=0x1 <asyncmap 0xa0000> <magic 0x349a0dc7> <pcomp> <accomp>]
Dec 17 13:25:11 localhost pppd[3152]: LCP: timeout sending Config-Requests
Dec 17 13:25:11 localhost pppd[3152]: Connection terminated.
Dec 17 13:25:11 localhost pppd[3152]: using channel 6
Dec 17 13:25:11 localhost pppd[3152]: Using interface ppp0
Dec 17 13:25:11 localhost pppd[3152]: Connect: ppp0 <--> /dev/ttyS0
Dec 17 13:25:11 localhost pppd[3152]: sent [LCP ConfReq id=0x2 <asyncmap 0xa0000> <magic 0x5b62c3e3> <pcomp> <accomp>]
Hmm. The pppd continues LCP negotiation after an initial Config-Req
timeout. Looks like a persist-related pppd option may be used, and it
seems that pppd 2.4.3 had a persist/demand bug.
Post by Daniel
Dec 17 13:25:11 localhost pppd[3152]: tcflush failed: Bad file descriptor
Dec 17 13:25:11 localhost pppd[3152]: tcsetattr: Invalid argument (line 1025)
Dec 17 13:25:11 localhost pppd[3152]: Exit.
This appears related to PPP/ttySx interfacing and might be due to a failed
modem connection or perhaps the persist bug, but that's only speculation.
Post by Daniel
Does this give anybody any clues?
And originally the log was telling me I was using channels 1 & 2 but now
I'm using (or trying, at least) to use channels 5 & 6. Are these channel
numbers on the ISP's modem or something else??
Something else, normal and not related to this problem. Maybe someone
will explain channels to both of us.

You might add S95=47 to the end of the kppp modem initialization string
which should provide more modem negotiation details - assuming kppp can
be configured to report or log them.
Post by Daniel
TIA
Daniel
--
Posted via a free Usenet account from http://www.teranews.com
--
Clifford Kite
/* The wealth of a nation is created by the productive labor of its
* citizens. */
Daniel
2006-12-27 13:05:07 UTC
Permalink
Post by Daniel
Dual Boot Win98 and Mandravis 2007 system. Posting this using my Win98
profile.
I'm away from home for a while, so I'm trying to set up kppp so it will
dial into my normal ISP so I can get my mail. Fortunately my ISP has a
portal or whatever you call it, so I'm not going to be paying long
distance 'phone rates.
When I dial in I get modem chatter for a couple of second then things go
quite (as I would expect) and the screen tells me it achieves connect
and starts pppd, but this final connection is never made. This is what
the kppp logfile looks like:-
Dec 17 13:24:41 localhost pppd[3152]: pppd 2.4.3 started by daniel, uid 500
Dec 17 13:24:41 localhost pppd[3152]: using channel 5
Dec 17 13:24:41 localhost pppd[3152]: Using interface ppp0
Dec 17 13:24:41 localhost pppd[3152]: Connect: ppp0 <--> /dev/ttyS0
Dec 17 13:24:41 localhost pppd[3152]: sent [LCP ConfReq id=0x1
<asyncmap 0xa0000> <magic 0x349a0dc7> <pcomp> <accomp>]
Dec 17 13:25:11 localhost pppd[3152]: LCP: timeout sending
Config-Requests Dec 17 13:25:11 localhost pppd[3152]: Connection
terminated.
Dec 17 13:25:11 localhost pppd[3152]: using channel 6
Dec 17 13:25:11 localhost pppd[3152]: Using interface ppp0
Dec 17 13:25:11 localhost pppd[3152]: Connect: ppp0 <--> /dev/ttyS0
Dec 17 13:25:11 localhost pppd[3152]: sent [LCP ConfReq id=0x2
<asyncmap 0xa0000> <magic 0x5b62c3e3> <pcomp> <accomp>]
Dec 17 13:25:11 localhost pppd[3152]: tcflush failed: Bad file descriptor
Dec 17 13:25:11 localhost pppd[3152]: tcsetattr: Invalid argument (line 1025)
Dec 17 13:25:11 localhost pppd[3152]: Exit.
Does this give anybody any clues?
And originally the log was telling me I was using channels 1 & 2 but now
I'm using (or trying, at least) to use channels 5 & 6. Are these channel
numbers on the ISP's modem or something else??
TIA
Daniel
After a Christmas break, I've decided to summaries the situation from
the other postings,so:-

On Dec 18th, Unruh had me put the line
daemon.*;local2.* /var/log/daemenlog
into /etc/syslog.conf and then run
killall -1 syslogd
and to make sure the word debug was in /etc/ppp/options

Done

Then ***@painkiller.example.tld (Moe Trin) sent in:-
LCP negotiations - peer hard of hearing. Doesn't look to me to be an
'asyncmap' (both proposing 0xa0000), or 'escape ff' problem. Peer never
seems to notice PAP AuthReq frame.

Old guy

Clifford Kite then commented that I was probably using the winmodem on
the Linux side but I'm actually using an external Motorola Lifestyle
28.8, if that makes a difference! He then examined the Kppp logfile and
commented:-
The pppd continues LCP negotiation after an initial Config-Req
timeout. Looks like a persist-related pppd option may be used, and it
seems that pppd 2.4.3 had a persist/demand bug.

and then, after the "call Exited", Cliff commented:-
This appears related to PPP/ttySx interfacing and might be due to a failed
modem connection or perhaps the persist bug, but that's only speculation.

On 19 Dec, Unruh wrote, quote:-
OK,
as root do
chmod +s /usr/bin/ppp

Also the far side is having trouble hearing you.
Try putting into /etc/ppp/options
asyncmap 0xa0000

The far end is a broken windows system.
end quote

Issuing the chmod gave quote:-
chmod: cannot access `/usr/bin/ppp': No such file or directory
End quote.

Then, on Tue, 19 Dec 2006 21:39:19 -0600, Clifford Kite wrote, Quote:-
Post by Daniel
Dec 15 20:54:40 localhost pppd[2919]: rcvd [LCP ConfReq id=0x1
<asyncmap
Post by Daniel
0xa0000> <auth pap> <magic 0x3c747bd6> <pcomp> <accomp> <mrru 1524>
<endpoint [local:61.61.70.74.76.69.63]>]
And here the peer seems not to have received pppd's "LCP ConfAck
id=0x2" since it ignores the "PAP AuthReq" and repeats it's first "LCP
ConfReq
id=0x1" request but drops only 2 of the 3 rejected options -and- includes
a magic number. It may be legal but it's weird.
End Quote

and, Quote
Post by Daniel
Dec 15 20:54:41 localhost pppd[2919]: rcvd [LCP ConfReq id=0xdf
<mru 1456>
Post by Daniel
<asyncmap 0xa0000> <auth pap> <magic 0x3c747bd6>]
An id number jump doesn't bother me since I don't think they need to
be sequential.
End quote

then, quote:-
Post by Daniel
Dec 15 20:54:41 localhost pppd[2919]: sent [LCP ConfAck id=0xdf
<mru 1456>
Post by Daniel
<asyncmap 0xa0000> <auth pap> <magic 0x3c747bd6>]
The id of a LCP Conf{Ack,Nak,Rej} need only match that of the last
ConfReq, as the ConfAck above does. RFC 1661, "5. LCP Packet Formats."
End quote

then, quote:-
Post by Daniel
Dec 15 20:54:41 localhost pppd[2919]: rcvd [LCP ConfRej id=0x3
<asyncmap
Post by Daniel
0xa0000> <pcomp> <accomp>]
-------------
Why the peer sends a LCP ConfRej for all requested options is beyond me.
End quote

then, part-quote:-
The OP can try adding the pppd option "default-asyncmap" - the PPP
default ACCM, escaping all CCs - and if that allows authentication to
proceed then
the peer was probably still expecting escaped characters while pppd had
begun using the ACCM because it had both received and sent an LCP ConfAck.
End part-quote

All of which produced the following in deamonlog:-
Dec 27 22:38:24 localhost pppd[3558]: pppd 2.4.3 started by root, uid 0
Dec 27 22:38:24 localhost pppd[3558]: using channel 1
Dec 27 22:38:24 localhost pppd[3558]: Using interface ppp0
Dec 27 22:38:24 localhost pppd[3558]: Connect: ppp0 <--> /dev/ttyS0
Dec 27 22:38:24 localhost pppd[3558]: sent [LCP ConfReq id=0x1 <asyncmap
0xa0000> <magic 0x68709551> <pcomp> <accomp>]
Dec 27 22:38:25 localhost pppd[3558]: rcvd [LCP ConfReq id=0x1 < 00 04
00 00> <mru 1524> <asyncmap 0xa0000> <auth pap> <pcomp> <accomp> <mrru
1524> <endpoint [local:73.74.61.63.6b]> < 17 04 6f 06>]
Dec 27 22:38:25 localhost pppd[3558]: sent [LCP ConfRej id=0x1 < 00 04
00 00> <mrru 1524> < 17 04 6f 06>]
Dec 27 22:38:25 localhost pppd[3558]: rcvd [LCP ConfAck id=0x1 <asyncmap
0xa0000> <magic 0x68709551> <pcomp> <accomp>]
Dec 27 22:38:25 localhost pppd[3558]: rcvd [LCP ConfReq id=0x2 <mru
1524> <asyncmap 0xa0000> <auth pap> <pcomp> <accomp> <endpoint
[local:73.74.61.63.6b]>]
Dec 27 22:38:25 localhost pppd[3558]: sent [LCP ConfAck id=0x2 <mru
1524> <asyncmap 0xa0000> <auth pap> <pcomp> <accomp> <endpoint
[local:73.74.61.63.6b]>]
Dec 27 22:38:25 localhost pppd[3558]: sent [PAP AuthReq id=0x1
user="***@roam.albury.net.au" password=<hidden>]
Dec 27 22:38:25 localhost pppd[3558]: rcvd [LCP ConfReq id=0x1 <asyncmap
0xa0000> <auth pap> <magic 0xc7ab09fe> <pcomp> <accomp> <mrru 1524>
<endpoint [local:61.61.70.74.76.69.63]>]
Dec 27 22:38:25 localhost pppd[3558]: sent [LCP ConfReq id=0x2 <asyncmap
0xa0000> <magic 0xcab875a5> <pcomp> <accomp>]
Dec 27 22:38:25 localhost pppd[3558]: sent [LCP ConfRej id=0x1 <mrru 1524>]
Dec 27 22:38:25 localhost pppd[3558]: rcvd [LCP ConfAck id=0x2 <asyncmap
0xa0000> <magic 0xcab875a5> <pcomp> <accomp>]
Dec 27 22:38:25 localhost pppd[3558]: rcvd [LCP ConfReq id=0x2 <asyncmap
0xa0000> <auth pap> <magic 0xc7ab09fe> <pcomp> <accomp> <endpoint
[local:61.61.70.74.76.69.63]>]
Dec 27 22:38:25 localhost pppd[3558]: sent [LCP ConfAck id=0x2 <asyncmap
0xa0000> <auth pap> <magic 0xc7ab09fe> <pcomp> <accomp> <endpoint
[local:61.61.70.74.76.69.63]>]
Dec 27 22:38:25 localhost pppd[3558]: sent [PAP AuthReq id=0x2
user="***@roam.albury.net.au" password=<hidden>]
Dec 27 22:38:25 localhost pppd[3558]: rcvd [LCP ConfReq id=0x79 <mru
1456> <asyncmap 0xa0000> <auth pap> <magic 0xc7ab09fe>]
Dec 27 22:38:25 localhost pppd[3558]: sent [LCP ConfReq id=0x3 <asyncmap
0xa0000> <magic 0x8bb8ad72> <pcomp> <accomp>]
Dec 27 22:38:25 localhost pppd[3558]: sent [LCP ConfAck id=0x79 <mru
1456> <asyncmap 0xa0000> <auth pap> <magic 0xc7ab09fe>]
Dec 27 22:38:26 localhost pppd[3558]: rcvd [LCP ConfRej id=0x3 <asyncmap
0xa0000> <pcomp> <accomp>]
Dec 27 22:38:26 localhost pppd[3558]: sent [LCP ConfReq id=0x4 <magic
0x8bb8ad72>]
Dec 27 22:38:26 localhost pppd[3558]: rcvd [LCP ConfAck id=0x4 <magic
0x8bb8ad72>]
Dec 27 22:38:26 localhost pppd[3558]: sent [PAP AuthReq id=0x3
user="***@roam.albury.net.au" password=<hidden>]
Dec 27 22:38:29 localhost pppd[3558]: sent [PAP AuthReq id=0x4
user="***@roam.albury.net.au" password=<hidden>]
Dec 27 22:38:32 localhost pppd[3558]: sent [PAP AuthReq id=0x5
user="***@roam.albury.net.au" password=<hidden>]
Dec 27 22:38:35 localhost pppd[3558]: sent [PAP AuthReq id=0x6
user="***@roam.albury.net.au" password=<hidden>]
Dec 27 22:38:38 localhost pppd[3558]: sent [PAP AuthReq id=0x7
user="***@roam.albury.net.au" password=<hidden>]
Dec 27 22:38:41 localhost pppd[3558]: sent [PAP AuthReq id=0x8
user="***@roam.albury.net.au" password=<hidden>]
Dec 27 22:38:44 localhost pppd[3558]: sent [PAP AuthReq id=0x9
user="***@roam.albury.net.au" password=<hidden>]
Dec 27 22:38:47 localhost pppd[3558]: sent [PAP AuthReq id=0xa
user="***@roam.albury.net.au" password=<hidden>]
Dec 27 22:38:50 localhost pppd[3558]: sent [PAP AuthReq id=0xb
user="***@roam.albury.net.au" password=<hidden>]
Dec 27 22:38:53 localhost pppd[3558]: sent [PAP AuthReq id=0xc
user="***@roam.albury.net.au" password=<hidden>]
Dec 27 22:38:56 localhost pppd[3558]: No response to PAP
authenticate-requests
Dec 27 22:38:56 localhost pppd[3558]: sent [LCP TermReq id=0x5 "Failed
to authenticate ourselves to peer"]
Dec 27 22:38:56 localhost pppd[3558]: rcvd [LCP TermAck id=0x5]
Dec 27 22:38:56 localhost pppd[3558]: Connection terminated.
Dec 27 22:38:56 localhost pppd[3558]: Exit.


and, as I was closing the terminal, I noticed some lines that were
interesting:-

[***@localhost daniel]# kppp
kbuildsycoca running...
KWrited - Listening on Device /dev/pts/2
Opener: received SetSecret
Opener: received SetSecret
Opener: received OpenLock
Opener: received OpenDevice
Opener: received ExecPPPDaemon
In parent: pppd pid 3417
Couldn't find interface ppp0: No such device
Kernel supports ppp alright.
It was pppd that died
pppd exited with return value 19
Sending 3399 a SIGUSR1
Opener: received RemoveSecret
Opener: received RemoveSecret
Opener: received OpenResolv
Opener: received OpenResolv
Opener: received RemoveLock
Opener: received PPPDExitStatus
Opener: received PPPDExitStatus
unix_connect: can't connect to server
(unix:/root/tmp/ksocket-root/localhost-0de0-459259a8)
Launched ok, pid = 3441
There are already artsd objects registered, looking if they are active...
... cleaned 5 unused mcop global references.

[***@localhost daniel]#

Does any of this help someone get me online using MD2007??

TIA

Daniel
--
Posted via a free Usenet account from http://www.teranews.com
Clifford Kite
2006-12-27 18:43:23 UTC
Permalink
Post by Daniel
Post by Daniel
Dual Boot Win98 and Mandravis 2007 system. Posting this using my Win98
profile.
...
Post by Daniel
Clifford Kite then commented that I was probably using the winmodem on
the Linux side but I'm actually using an external Motorola Lifestyle
28.8, if that makes a difference! He then examined the Kppp logfile and
It makes a difference in that win/HCF/HSF "modems" are driven in part by
software, which makes them more of an unknown quantity than a real modem.
And, to the best of my knowledge, all external modems are real modems.
Post by Daniel
commented:-
The other comments are now pretty much irrelevant.
...
Post by Daniel
All of which produced the following in deamonlog:-
Dec 27 22:38:24 localhost pppd[3558]: pppd 2.4.3 started by root, uid 0
Dec 27 22:38:24 localhost pppd[3558]: using channel 1
Dec 27 22:38:24 localhost pppd[3558]: Using interface ppp0
Dec 27 22:38:24 localhost pppd[3558]: Connect: ppp0 <--> /dev/ttyS0
Dec 27 22:38:24 localhost pppd[3558]: sent [LCP ConfReq id=0x1 <asyncmap
0xa0000> <magic 0x68709551> <pcomp> <accomp>]
Try adding the pppd option "default-asyncmap" to determine if it's a
race condition causing the problem. This option forces both sides to
use the Point to Point _Protocol_ default asyncmap so that all control
characters are escaped in both directions. If that option allows the
negotiations to complete then it is a race condition. This really needs
to be resolved before any more dialog on the problem takes place.

The rest of the PPP log is essentially a replay of the previous log.
...
Post by Daniel
and, as I was closing the terminal, I noticed some lines that were
interesting:-
It's kppp being kppp..
...
Post by Daniel
Does any of this help someone get me online using MD2007??
Well, not me, not yet. And from the lack of significant hits by a couple
of google searches it doesn't appear likely that anyone else will either.
Hope I'm wrong about that.
Post by Daniel
TIA
Daniel
--
Posted via a free Usenet account from http://www.teranews.com
--
Clifford Kite
Daniel
2006-12-29 00:16:08 UTC
Permalink
Post by Clifford Kite
Post by Daniel
Post by Daniel
Dual Boot Win98 and Mandravis 2007 system. Posting this using my Win98
profile.
...
Post by Daniel
Clifford Kite then commented that I was probably using the winmodem on
the Linux side but I'm actually using an external Motorola Lifestyle
28.8, if that makes a difference! He then examined the Kppp logfile and
It makes a difference in that win/HCF/HSF "modems" are driven in part by
software, which makes them more of an unknown quantity than a real modem.
And, to the best of my knowledge, all external modems are real modems.
Post by Daniel
commented:-
The other comments are now pretty much irrelevant.
...
Post by Daniel
All of which produced the following in deamonlog:-
Dec 27 22:38:24 localhost pppd[3558]: pppd 2.4.3 started by root, uid 0
Dec 27 22:38:24 localhost pppd[3558]: using channel 1
Dec 27 22:38:24 localhost pppd[3558]: Using interface ppp0
Dec 27 22:38:24 localhost pppd[3558]: Connect: ppp0 <--> /dev/ttyS0
Dec 27 22:38:24 localhost pppd[3558]: sent [LCP ConfReq id=0x1 <asyncmap
0xa0000> <magic 0x68709551> <pcomp> <accomp>]
Try adding the pppd option "default-asyncmap" to determine if it's a
race condition causing the problem. This option forces both sides to
use the Point to Point _Protocol_ default asyncmap so that all control
characters are escaped in both directions. If that option allows the
negotiations to complete then it is a race condition. This really needs
to be resolved before any more dialog on the problem takes place.
The rest of the PPP log is essentially a replay of the previous log.
...
Post by Daniel
and, as I was closing the terminal, I noticed some lines that were
interesting:-
It's kppp being kppp..
...
Post by Daniel
Does any of this help someone get me online using MD2007??
Well, not me, not yet. And from the lack of significant hits by a couple
of google searches it doesn't appear likely that anyone else will either.
Hope I'm wrong about that.
Post by Daniel
TIA
Daniel
--
Posted via a free Usenet account from http://www.teranews.com
You da man, Clifford, You da man!!

I added your "default-asyncmap" to the options file, after the asyncmap
0xa0000 line, and I can now dial in and get on the net, bit slow at 9600
baud, but I'll work on that.

Thank you, one and all.

Daniel
--
Posted via a free Usenet account from http://www.teranews.com
Moe Trin
2006-12-28 00:25:26 UTC
Permalink
On Thu, 28 Dec 2006, in the Usenet newsgroup comp.protocols.ppp, in article
Post by Daniel
Clifford Kite then commented that I was probably using the winmodem on
the Linux side but I'm actually using an external Motorola Lifestyle
28.8, if that makes a difference!
I know his concern - winmodems use software to emulate hardware that
wasn't installed in a cost reduction trick. The problem for the Linux
user is that nearly all of the winmodem drivers we use are created by
volunteers without access to the manufacturers data, and as a result
may not be as complete as the windoze version (which is created by
that manufacturer with full access to the hardware and to the O/S).
We've seen cases where an imperfect driver caused problems. Hardware
modems such as your Motorola external, don't have this problem.
Post by Daniel
On 19 Dec, Unruh wrote, quote:-
OK,
as root do
chmod +s /usr/bin/ppp
Issuing the chmod gave quote:-
chmod: cannot access `/usr/bin/ppp': No such file or directory
End quote.
Typ0 - that would be /usr/sbin/pppd - but it's not a factor here.
Post by Daniel
All of which produced the following in deamonlog:-
[no obvious change] Darn!

I'm grasping at straws - I wonder what effect 'noendpoint' or 'nomp' as
an option to your system would have. You'd set this option in the same
way you've set 'asyncmap 0x0a0000'.
Post by Daniel
and, as I was closing the terminal, I noticed some lines that were
interesting:-
Yeah, that's another reason none of us use kppp - but I don't think this
is significant. You seem to have been able to dial, and send the desired
username/password, so this is pure KDE crap.
Post by Daniel
Couldn't find interface ppp0: No such device
Kernel supports ppp alright.
It was pppd that died
pppd exited with return value 19
and 'man pppd' would show (under EXIT STATUS)

19 We failed to authenticate ourselves to the peer.

because indeed we never did manage to get the username/password noticed.

Old guy
Loading...