PAP often fails: log decode ?

In my previous thread: debug dialup login & why don't ISP's show engaged ?

Moe Trin wrote:-
> Your script includes the 'debug' option. Do you have /etc/syslog.conf
> set to log 'daemon.=debug /var/log/ppp.debug' and see that you
> are sending the "right" username and password? See the
> 'syslog.conf'
> man page if necessary, and restart 'sysklogd' if you alter that file.

OK thanks.
Today it's bad. I'm repeatedly charged to connect with failures !!
Log shows:---------
May 4 14:11:14 localhost pppd[7995]: pppd 2.4.1 started by root, uid 0
May 4 14:11:35 localhost pppd[7995]: Serial connection established.
May 4 14:11:35 localhost pppd[7995]: using channel 33
May 4 14:11:35 localhost pppd[7995]: Using interface ppp0
May 4 14:11:35 localhost pppd[7995]: Connect: ppp0 <--> /dev/ttyS1
May 4 14:11:36 localhost pppd[7995]
: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x530d0bc1> <pcomp> <accomp>]
: rcvd [LCP ConfReq id=0xe1 <asyncmap 0xa0000> <auth pap> <magic 0x7f09d130>
<pcomp> <accomp> <mrru 1524> <endpoint [local:69.73.64.6e.78.32]>]
May 4 14:11:37 localhost pppd[7995]: sent [LCP ConfRej id=0xe1 <mrru 1524>]
May 4 14:11:37 localhost pppd[7995]
: rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x530d0bc1> <pcomp> <accomp>]
: rcvd [LCP ConfReq id=0xe2 <asyncmap 0xa0000> <auth pap> <magic 0x7f09d130>
<pcomp> <accomp> <endpoint [local:69.73.64.6e.78.32]>]
: sent [LCP ConfAck id=0xe2 <asyncmap 0xa0000> <auth pap> <magic 0x7f09d130>
<pcomp> <accomp> <endpoint [local:69.73.64.6e.78.32]>]
May 4 14:11:37 localhost pppd[7995]: sent [LCP EchoReq id=0x0 magic=0x530d0bc1]
: sent [PAP AuthReq id=0x1 user="2nm4nx6x@za" password=<hidden>]
May 4 14:11:37 localhost pppd[7995]: rcvd [LCP EchoRep id=0x0 magic=0x7f09d130]
: rcvd [PAP AuthNak id=0x1 "Authentication failed"]
May 4 14:11:37 localhost pppd[7995]: Remote message: Authentication failed
: sent [LCP TermReq id=0x2 "Failed to authenticate ourselves to peer"]
May 4 14:11:37 localhost pppd[7995]: rcvd [LCP TermAck id=0x2]
May 4 14:11:37 localhost pppd[7995]: Connection terminated.
May 4 14:11:37 localhost pppd[7995]: Hangup (SIGHUP)
May 4 14:11:37 localhost pppd[7995]: Exit.
---------- and for the next try:-------
May 4 14:11:54 localhost pppd[8017]: pppd 2.4.1 started by root, uid 0
May 4 14:12:18 localhost pppd[8017]: Serial connection established.
May 4 14:12:18 localhost pppd[8017]: using channel 34
May 4 14:12:18 localhost pppd[8017]: Using interface ppp0
May 4 14:12:18 localhost pppd[8017]: Connect: ppp0 <--> /dev/ttyS1
: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x6f38fe2d> <pcomp> <accomp>]
: rcvd [LCP ConfReq id=0xba <asyncmap 0xa0000> <auth pap> <magic 0x54714d4d>
<pcomp> <accomp> <mrru 1524> <endpoint [local:69.73.64.6e.78.32]>]
: sent [LCP ConfRej id=0xba <mrru 1524>]
: rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x6f38fe2d> <pcomp> <accomp>]
: rcvd [LCP ConfReq id=0xbb <asyncmap 0xa0000> <auth pap> <magic 0x54714d4d>
<pcomp> <accomp> <endpoint [local:69.73.64.6e.78.32]>]
: sent [LCP ConfAck id=0xbb <asyncmap 0xa0000> <auth pap> <magic 0x54714d4d>
<pcomp> <accomp> <endpoint [local:69.73.64.6e.78.32]>]
: sent [LCP EchoReq id=0x0 magic=0x6f38fe2d]
: sent [PAP AuthReq id=0x1 user="2nm4nx6x@za" password=<hidden>]
May 4 14:12:20 localhost pppd[8017]: rcvd [LCP EchoRep id=0x0 magic=0x54714d4d]
: rcvd [PAP AuthNak id=0x1 "Authentication failed"]
May 4 14:12:20 localhost pppd[8017]: Remote message: Authentication failed
: sent [LCP TermReq id=0x2 "Failed to authenticate ourselves to peer"]
May 4 14:12:20 localhost pppd[8017]: rcvd [LCP TermAck id=0x2]
May 4 14:12:20 localhost pppd[8017]: Connection terminated.
May 4 14:12:21 localhost pppd[8017]: Hangup (SIGHUP)
May 4 14:12:21 localhost pppd[8017]: Exit.
-------------

Does the 'error correction mechanism' work before PAP
is confirmed ?
If the problem is 'line errors' then why is this not a problem
AFTER is pap-confirmed ?
The ID & pswrd are auto-sent, without human intervention/error.

I think the idiots are just giving a pap-error, when they have
congestion 'down line' instead of sending an off-hook/engaged
signal up-line. In so doing, costing me futile connection charges.

== Chris Glur.



Although this NewsGroup still functions well,
there are already many other previously good
NewsGroups which have been crowed-out by
the twittering-idiot-masses. To avoid further
displacement of the NNT-protocol by the
dumbed-down inefficient clik-blogs, we need
to take a stand.