Hi Dave,
Short version: =20
It looks like the LCP negotiation went fine but then the remote=20
end hung up at the place where authentication would normally
take place. =20
I'm not sure, but it seems to me like there is some confusion about
who is supposed to do the authentication or this looks like a=20
callout from the PM to the remote side.
Sorry, I'm stumped. =20
Maybe the data will help you. (I'm not 100% sure of the annotations)
Regards,
Bill
Long Version:
(Recall each direction on the link is negotiated separately).
>Found Livingston dump format
>Sending LCP_CONFIGURE_REQUEST to port S22 of 14 bytes containing:
>01 01 00 0e 05 06 2f 4d 9c 83 03 04 c0 23=20
>Sent to port S22: 16 bytes LCP Request-1=20
> Magic-Number =3D 0x2f4d9c83
> Authentication-Protocol =3D PAP=20
PM asks for a vanilla single link PPP set of options
PM offers to authenticate itself to the remote side!
>Received LCP_CONFIGURE_REQUEST on port S22 of 12 bytes containing:
>01 01 00 10 11 04 05 f6 01 04 05 f6 08 02 07 02=20
>Fixed #bytes to match #found...
>Recvd from port S22: 18 bytes LCP Request-1=20
> MP-MRRU =3D 1526
> Max-Recieve-Unit =3D 1526
> Addr-and-Ctl-Field-Comp
> Protocol-Field-Comp=20
The remote asks for a MP capable connection from it to the PM.
The remote does not offer to authenticate itself!
>Sending LCP_CONFIGURE_REQUEST to port S22 of 29 bytes containing:
>01 02 00 1d 05 06 2f 4d 9c 83 03 04 c0 23 11 04=20
>06 1c 12 02 13 09 03 00 c0 05 01 47 d6=20
>Sent to port S22: 31 bytes LCP Request-2=20
> Magic-Number =3D 0x2f4d9c83
> Authentication-Protocol =3D PAP
> MP-MRRU =3D 1564
> MP-Short-Seq-Num-Header
> MP-Endpoint-Disc =3D 0x0300c0050147d6=20
PM re-bids to do MP from it to remote.
Still willing to authenticate itself.
>Sending LCP_CONFIGURE_ACK to port S22 of 16 bytes containing:
>02 01 00 10 11 04 05 f6 01 04 05 f6 08 02 07 02=20
>Sent to port S22: 18 bytes LCP Accept-1=20
> MP-MRRU =3D 1526
> Max-Recieve-Unit =3D 1526
> Addr-and-Ctl-Field-Comp
> Protocol-Field-Comp=20
PM accepts the remotes request to do MP from it to the PM
The LCP layer from the remote to the PM is successfully negotiated.
>Received LCP_CONFIGURE_ACK on port S22 of 10 bytes containing:
>02 01 00 0e 05 06 2f 4d 9c 83 03 04 c0 23=20
>Fixed #bytes to match #found...
>Recvd from port S22: 16 bytes LCP Accept-1=20
> Magic-Number =3D 0x2f4d9c83
> Authentication-Protocol =3D PAP=20
>Skipping: Discarding PPP on port S22 - reply to old request
PM gets the remote end's ACK to its original request (now out of date)
>Received LCP_CONFIGURE_REJECT on port S22 of 2 bytes containing:
>04 02 00 06 12 02=20
>Fixed #bytes to match #found...
>Recvd from port S22: 8 bytes LCP Reject-2=20
> MP-Short-Seq-Num-Header=20
PM gets a NAK on part of its MP request (remote doesn't want short seq#)
>Sending LCP_CONFIGURE_REQUEST to port S22 of 27 bytes containing:
>01 03 00 1b 05 06 2f 4d 9c 83 03 04 c0 23 11 04=20
>06 1c 13 09 03 00 c0 05 01 47 d6=20
>Sent to port S22: 29 bytes LCP Request-3=20
> Magic-Number =3D 0x2f4d9c83
> Authentication-Protocol =3D PAP
> MP-MRRU =3D 1564
> MP-Endpoint-Disc =3D 0x0300c0050147d6=20
PM re-bids its MP offer (without SSN now).
>Received LCP_CONFIGURE_ACK on port S22 of 23 bytes containing:
>02 03 00 1b 05 06 2f 4d 9c 83 03 04 c0 23 11 04=20
>06 1c 13 09 03 00 c0 05 01 47 d6=20
>Fixed #bytes to match #found...
>Recvd from port S22: 29 bytes LCP Accept-3=20
> Magic-Number =3D 0x2f4d9c83
> Authentication-Protocol =3D PAP
> MP-MRRU =3D 1564
> MP-Endpoint-Disc =3D 0x0300c0050147d6=20
PM receives an ACK from the remote for its requested options.
The LCP layer from the PM to the remote is negotiated
Remote says it's willing to hear the PM's authentication.
>Skipping: S22: LCP Open
Normally, PAP (password authentication) would take place here.
Instead, it looks like the remote end hangs up. ?!?
>Skipping: S22: Received Disconnect Normal Clearing
>Skipping: net: Bad wanted 59771, got 25
>Skipping: S22: Received Call Clear=20
>Skipping: S22: Session Terminated - Lost Carrier