Remote tears down link during PAP

[m***@waste.org]

Greetings:

We are trying to establish DSL service with an ISP who won't cooperate
with PPP troubleshooting. The problem is an unqualified tear down of
the open PPP link after PAP sends our UID and PWD. Here is a debug
log of the PPP negotiation and state transitions from our DSL router
(Efficient 5861); the codes, actions and states conform to RFC 1661.

Can anyone shed some light on what is going on here?

Regards,

Michael Grigoni
Cybertheque Museum


# 01/18/2006-15:48:02:DOD: connecting to <cpro_1> using 0*32 over
ATM-VC/1
NCP: LCP: opening NCP connection: s/w control
NCP: LCP: state 0, event 2, actions 10
LCP: Event 10 notification!
LCP: TLS
NCP: LCP: state 0, event 2, to state 1
NCP: LCP: state 1, event 0, actions 240
NCP: LCP: sending code 1, len=19, id=1
code 1: 06 0c
code 3: c2 23 05
code 5: fa b7 88 4d
NCP: LCP: state 1, event 0, to state 6
LCP: LCP: RX len=19, reallen=19, code=2 id=1, state=6
NCP: LCP: RX len=19, reallen=19, code=2 id=1, state=6
code 1 len 4... 6 c ...processed
code 3 len 5... c2 23 5 ...processed
code 5 len 6... fa b7 88 4d ...processed
NCP: LCP: state 6, event 8, actions 40
NCP: LCP: state 6, event 8, to state 7
NCP: LCP: state 7, event 4, actions 200
NCP: LCP: sending code 1, len=19, id=2
code 1: 06 0c
code 3: c2 23 05
code 5: fa b7 88 4d
NCP: LCP: state 7, event 4, to state 6
LCP: LCP: RX len=19, reallen=19, code=2 id=2, state=6
NCP: LCP: RX len=19, reallen=19, code=2 id=2, state=6
code 1 len 4... 6 c ...processed
code 3 len 5... c2 23 5 ...processed
code 5 len 6... fa b7 88 4d ...processed
NCP: LCP: state 6, event 8, actions 40
NCP: LCP: state 6, event 8, to state 7
LCP: LCP: RX len=14, reallen=14, code=1 id=c, state=7
NCP: LCP: RX len=14, reallen=14, code=1 id=c, state=7
ACK
code 3 len 4... c0 23 ...ACK
code 5 len 6... d3 29 6e ec ...ACK
ACK
NCP: LCP: state 7, event 6, actions 402
NCP: LCP: sending code 2, len=14, id=c
code 3: c0 23
code 5: d3 29 6e ec
LCP: Event 2 notification!
LCP: TLU pppp = 0x3384ac
PPP: LCP: wewish 261 wemust 0 wegot 221
PPP: LCP: wecan 273 weacked 240
PPP: LCP: our magic fab7884d their magic d3296eec
PPP: LCP: our mru 1548 their mru 1500
PPP: LCP: our mrru 1548 their mrru 0
LCP: start authen
CHAP: send challenge, seq 1

**** NOTE: here we send our UID and PWD ***

PAP: send id=<username> pwd=<password>, seq 2
NCP: LCP: state 7, event 6, to state 9

**** NOTE: here the link is up (state 9) ****

01/18/2006-15:48:02:PPP: using bi-directional authentication with
remote <cpro_1>

**** NOTE: here we receive a terminate request (code 5) ****

LCP: LCP: RX len=4, reallen=4, code=5 id=d, state=9
NCP: LCP: RX len=4, reallen=4, code=5 id=d, state=9
NCP: LCP: state 9, event 10, actions 4104
LCP: Event 4 notification!
LCP: TLD pppp = 0x3384ac
NCP: LCP: sending code 6, len=4, id=d
NCP: LCP: state 9, event 10, to state 5
LCP: LCP: RX len=14, reallen=14, code=1 id=e, state=5
NCP: LCP: RX len=14, reallen=14, code=1 id=e, state=5
ACK
code 3 len 4... c0 23 ...ACK
code 5 len 6... d3 29 ae 24 ...ACK
ACK
NCP: LCP: state 5, event 6, to state 5
NCP: LCP: state 5, event 5, actions 20
LCP: Event 20 notification!
LCP: TLF
NCP: LCP: state 5, event 5, to state 3
NCP: LCP: state 3, event 1, actions 10
LCP: Event 10 notification!
LCP: TLS

**** NOTE: end of orderly shutdown ****

NCP: LCP: state 3, event 1, to state 1

[Patrick Klos]

Post by m***@waste.org
We are trying to establish DSL service with an ISP who won't cooperate
with PPP troubleshooting. The problem is an unqualified tear down of
the open PPP link after PAP sends our UID and PWD. Here is a debug
log of the PPP negotiation and state transitions from our DSL router
(Efficient 5861); the codes, actions and states conform to RFC 1661.
Can anyone shed some light on what is going on here?
Regards,
Michael Grigoni
Cybertheque Museum
# 01/18/2006-15:48:02:DOD: connecting to <cpro_1> using 0*32 over
ATM-VC/1
NCP: LCP: opening NCP connection: s/w control
NCP: LCP: state 0, event 2, actions 10
LCP: Event 10 notification!
LCP: TLS
NCP: LCP: state 0, event 2, to state 1
NCP: LCP: state 1, event 0, actions 240
NCP: LCP: sending code 1, len=19, id=1
code 1: 06 0c
code 3: c2 23 05

Your implementation is telling the ISP that you expect the ISP to
authenticate itself to you by way of CHAP (MD5). This is very likely
a problem.

Post by m***@waste.org
code 5: fa b7 88 4d
NCP: LCP: state 1, event 0, to state 6
LCP: LCP: RX len=19, reallen=19, code=2 id=1, state=6
NCP: LCP: RX len=19, reallen=19, code=2 id=1, state=6
code 1 len 4... 6 c ...processed
code 3 len 5... c2 23 5 ...processed

Of course, I don't know why the ISP would ACK your demand that it
authenticate itself with CHAP?!? Maybe they've got a config error
as well?

Post by m***@waste.org
code 5 len 6... fa b7 88 4d ...processed
NCP: LCP: state 6, event 8, actions 40
NCP: LCP: state 6, event 8, to state 7
NCP: LCP: state 7, event 4, actions 200
NCP: LCP: sending code 1, len=19, id=2
code 1: 06 0c
code 3: c2 23 05
code 5: fa b7 88 4d
NCP: LCP: state 7, event 4, to state 6
LCP: LCP: RX len=19, reallen=19, code=2 id=2, state=6
NCP: LCP: RX len=19, reallen=19, code=2 id=2, state=6
code 1 len 4... 6 c ...processed
code 3 len 5... c2 23 5 ...processed
code 5 len 6... fa b7 88 4d ...processed
NCP: LCP: state 6, event 8, actions 40
NCP: LCP: state 6, event 8, to state 7
LCP: LCP: RX len=14, reallen=14, code=1 id=c, state=7
NCP: LCP: RX len=14, reallen=14, code=1 id=c, state=7
ACK
code 3 len 4... c0 23 ...ACK

The ISP asks you to authenticate yourself with PAP. That looks OK.

Post by m***@waste.org
code 5 len 6... d3 29 6e ec ...ACK
ACK
NCP: LCP: state 7, event 6, actions 402
NCP: LCP: sending code 2, len=14, id=c
code 3: c0 23
code 5: d3 29 6e ec
LCP: Event 2 notification!
LCP: TLU pppp = 0x3384ac
PPP: LCP: wewish 261 wemust 0 wegot 221
PPP: LCP: wecan 273 weacked 240
PPP: LCP: our magic fab7884d their magic d3296eec
PPP: LCP: our mru 1548 their mru 1500
PPP: LCP: our mrru 1548 their mrru 0
LCP: start authen
CHAP: send challenge, seq 1

Again, your side requiring the ISP to authenticate itself is very likely
not the right thing.

Post by m***@waste.org
**** NOTE: here we send our UID and PWD ***
PAP: send id=<username> pwd=<password>, seq 2
NCP: LCP: state 7, event 6, to state 9
**** NOTE: here the link is up (state 9) ****
01/18/2006-15:48:02:PPP: using bi-directional authentication with
remote <cpro_1>
**** NOTE: here we receive a terminate request (code 5) ****

Probably because the peer decided it doesn't like your CHAP challenge??

Post by m***@waste.org
LCP: LCP: RX len=4, reallen=4, code=5 id=d, state=9
NCP: LCP: RX len=4, reallen=4, code=5 id=d, state=9
NCP: LCP: state 9, event 10, actions 4104
LCP: Event 4 notification!
LCP: TLD pppp = 0x3384ac
NCP: LCP: sending code 6, len=4, id=d
NCP: LCP: state 9, event 10, to state 5
LCP: LCP: RX len=14, reallen=14, code=1 id=e, state=5
NCP: LCP: RX len=14, reallen=14, code=1 id=e, state=5
ACK
code 3 len 4... c0 23 ...ACK
code 5 len 6... d3 29 ae 24 ...ACK
ACK
NCP: LCP: state 5, event 6, to state 5
NCP: LCP: state 5, event 5, actions 20
LCP: Event 20 notification!
LCP: TLF
NCP: LCP: state 5, event 5, to state 3
NCP: LCP: state 3, event 1, actions 10
LCP: Event 10 notification!
LCP: TLS
**** NOTE: end of orderly shutdown ****
NCP: LCP: state 3, event 1, to state 1

Hope that helps? Let us know.

Patrick
=========== For PPP Protocol Analysis, check out PacketView Pro! ===========
Patrick Klos Email: ***@klos.com
Klos Technologies, Inc. Web: http://www.klos.com/
==================== http://www.loving-long-island.com/ ====================

[m***@waste.org]

Post by m***@waste.org
PPP: using bi-directional authentication with

remote <cpro_1>

Yes, this was the problem and I think they are
also misconfigured to ACK the challenge
from our end and then shutdown.

When we disabled our auth. demand it worked.

Thanks much!

Michael

[Unruh]

***@waste.org writes:


I must ssay that the debug log is short on information and in a form that I
cannot read. The thing that triggers a concern in me is the
line before the sending of the pap, namely the chap challenge sent. Either
you are demanding that they authenticate themselves to you via chap or
something is weird. Noone that I know of uses both chap and pap.

Post by m***@waste.org
We are trying to establish DSL service with an ISP who won't cooperate
with PPP troubleshooting. The problem is an unqualified tear down of
the open PPP link after PAP sends our UID and PWD. Here is a debug
log of the PPP negotiation and state transitions from our DSL router
(Efficient 5861); the codes, actions and states conform to RFC 1661.
Can anyone shed some light on what is going on here?
Regards,
Michael Grigoni
Cybertheque Museum
# 01/18/2006-15:48:02:DOD: connecting to <cpro_1> using 0*32 over
ATM-VC/1
NCP: LCP: opening NCP connection: s/w control
NCP: LCP: state 0, event 2, actions 10
LCP: Event 10 notification!
LCP: TLS
NCP: LCP: state 0, event 2, to state 1
NCP: LCP: state 1, event 0, actions 240
NCP: LCP: sending code 1, len=19, id=1
code 1: 06 0c
code 3: c2 23 05
code 5: fa b7 88 4d
NCP: LCP: state 1, event 0, to state 6
LCP: LCP: RX len=19, reallen=19, code=2 id=1, state=6
NCP: LCP: RX len=19, reallen=19, code=2 id=1, state=6
code 1 len 4... 6 c ...processed
code 3 len 5... c2 23 5 ...processed
code 5 len 6... fa b7 88 4d ...processed
NCP: LCP: state 6, event 8, actions 40
NCP: LCP: state 6, event 8, to state 7
NCP: LCP: state 7, event 4, actions 200
NCP: LCP: sending code 1, len=19, id=2
code 1: 06 0c
code 3: c2 23 05
code 5: fa b7 88 4d
NCP: LCP: state 7, event 4, to state 6
LCP: LCP: RX len=19, reallen=19, code=2 id=2, state=6
NCP: LCP: RX len=19, reallen=19, code=2 id=2, state=6
code 1 len 4... 6 c ...processed
code 3 len 5... c2 23 5 ...processed
code 5 len 6... fa b7 88 4d ...processed
NCP: LCP: state 6, event 8, actions 40
NCP: LCP: state 6, event 8, to state 7
LCP: LCP: RX len=14, reallen=14, code=1 id=c, state=7
NCP: LCP: RX len=14, reallen=14, code=1 id=c, state=7
ACK
code 3 len 4... c0 23 ...ACK
code 5 len 6... d3 29 6e ec ...ACK
ACK
NCP: LCP: state 7, event 6, actions 402
NCP: LCP: sending code 2, len=14, id=c
code 3: c0 23
code 5: d3 29 6e ec
LCP: Event 2 notification!
LCP: TLU pppp = 0x3384ac
PPP: LCP: wewish 261 wemust 0 wegot 221
PPP: LCP: wecan 273 weacked 240
PPP: LCP: our magic fab7884d their magic d3296eec
PPP: LCP: our mru 1548 their mru 1500
PPP: LCP: our mrru 1548 their mrru 0
LCP: start authen
CHAP: send challenge, seq 1
**** NOTE: here we send our UID and PWD ***
PAP: send id=<username> pwd=<password>, seq 2
NCP: LCP: state 7, event 6, to state 9
**** NOTE: here the link is up (state 9) ****
01/18/2006-15:48:02:PPP: using bi-directional authentication with
remote <cpro_1>
**** NOTE: here we receive a terminate request (code 5) ****
LCP: LCP: RX len=4, reallen=4, code=5 id=d, state=9
NCP: LCP: RX len=4, reallen=4, code=5 id=d, state=9
NCP: LCP: state 9, event 10, actions 4104
LCP: Event 4 notification!
LCP: TLD pppp = 0x3384ac
NCP: LCP: sending code 6, len=4, id=d
NCP: LCP: state 9, event 10, to state 5
LCP: LCP: RX len=14, reallen=14, code=1 id=e, state=5
NCP: LCP: RX len=14, reallen=14, code=1 id=e, state=5
ACK
code 3 len 4... c0 23 ...ACK
code 5 len 6... d3 29 ae 24 ...ACK
ACK
NCP: LCP: state 5, event 6, to state 5
NCP: LCP: state 5, event 5, actions 20
LCP: Event 20 notification!
LCP: TLF
NCP: LCP: state 5, event 5, to state 3
NCP: LCP: state 3, event 1, actions 10
LCP: Event 10 notification!
LCP: TLS
**** NOTE: end of orderly shutdown ****
NCP: LCP: state 3, event 1, to state 1