Re: ISDN trace - bafflement

John G. Thompson (jgt10@livingston.com)
Wed, 9 Oct 1996 08:57:25 -0700 (PDT)

On Wed, 9 Oct 1996, Bill Lutton wrote:
>
> On Mon, 7 Oct 1996 20:16:52 -0600 (MDT), you wrote:
> >I'm not entirely sure what parts of this LCP conversation translate to.
> >It's an ISDN customer using a Courier I-Modem trying to get a Sync PPP
> >connection. We can establish an async PPP connection without much
> >trouble.
> >
> >Someone care to clue me in? (Promises of eternal gratitude may be
> >inserted here).
> >
> > - Dave
>
> Hi Dave,
>
> Short version:
> It looks like the LCP negotiation went fine but then the remote
> end hung up at the place where authentication would normally
> take place.
> 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
> callout from the PM to the remote side.

Pms do not authenticate themselves to the remote end via PAP.
don't think they authenticate to dial in connections at all.

> Sorry, I'm stumped.
> Maybe the data will help you. (I'm not 100% sure of the annotations)
>
> 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
> >Sent to port S22: 16 bytes LCP Request-1
> > Magic-Number = 0x2f4d9c83
> > Authentication-Protocol = PAP
>
> PM asks for a vanilla single link PPP set of options
> PM offers to authenticate itself to the remote side!

Not quite. The PM is requesting the remote end authenticate via
PAP to the PM.

> >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
> >Fixed #bytes to match #found...
> >Recvd from port S22: 18 bytes LCP Request-1
> > MP-MRRU = 1526
> > Max-Recieve-Unit = 1526
> > Addr-and-Ctl-Field-Comp
> > Protocol-Field-Comp
>
> The remote asks for a MP capable connection from it to the PM.
> The remote does not offer to authenticate itself!

The remote does not offer an authentication protocol. It is not
an offer kind of situation.

> >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
> >06 1c 12 02 13 09 03 00 c0 05 01 47 d6
> >Sent to port S22: 31 bytes LCP Request-2
> > Magic-Number = 0x2f4d9c83
> > Authentication-Protocol = PAP
> > MP-MRRU = 1564
> > MP-Short-Seq-Num-Header
> > MP-Endpoint-Disc = 0x0300c0050147d6
>
> PM re-bids to do MP from it to remote.
> Still willing to authenticate itself.

PM still trying to get remote to okay PAP.

> >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
> >Sent to port S22: 18 bytes LCP Accept-1
> > MP-MRRU = 1526
> > Max-Recieve-Unit = 1526
> > Addr-and-Ctl-Field-Comp
> > Protocol-Field-Comp
>
> 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.

The LCP isn't quite done. You would see 'LCP open' when the negotiation
is successful.

> >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
> >Fixed #bytes to match #found...
> >Recvd from port S22: 16 bytes LCP Accept-1
> > Magic-Number = 0x2f4d9c83
> > Authentication-Protocol = PAP
> >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)

Yes.

> >Received LCP_CONFIGURE_REJECT on port S22 of 2 bytes containing:
> >04 02 00 06 12 02
> >Fixed #bytes to match #found...
> >Recvd from port S22: 8 bytes LCP Reject-2
> > MP-Short-Seq-Num-Header
>
> PM gets a NAK on part of its MP request (remote doesn't want short seq#)

Correct.

> >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
> >06 1c 13 09 03 00 c0 05 01 47 d6
> >Sent to port S22: 29 bytes LCP Request-3
> > Magic-Number = 0x2f4d9c83
> > Authentication-Protocol = PAP
> > MP-MRRU = 1564
> > MP-Endpoint-Disc = 0x0300c0050147d6
>
> PM re-bids its MP offer (without SSN now).

Correct.

> >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
> >06 1c 13 09 03 00 c0 05 01 47 d6
> >Fixed #bytes to match #found...
> >Recvd from port S22: 29 bytes LCP Accept-3
> > Magic-Number = 0x2f4d9c83
> > Authentication-Protocol = PAP
> > MP-MRRU = 1564
> > MP-Endpoint-Disc = 0x0300c0050147d6
>
> PM receives an ACK from the remote for its requested options.
> The LCP layer from the PM to the remote is negotiated

The LCP layer is open, as indicated by the following LCP open.
The authentication protocol has not been set. Not sure what
will happen.

> Remote says it's willing to hear the PM's authentication.

Remote has said nothing about authentication.

> >Skipping: S22: LCP Open
>
> Normally, PAP (password authentication) would take place here.
> Instead, it looks like the remote end hangs up. ?!?

Yes, the remote hungup.

> >Skipping: S22: Received Disconnect Normal Clearing
> >Skipping: net: Bad wanted 59771, got 25
> >Skipping: S22: Received Call Clear
> >Skipping: S22: Session Terminated - Lost Carrier

JGT

--
John G. Thompson      Livingston Enterprises Inc.    Phone: (800) 458-9966
JOAT(MON)             6920-220 Koll Centre Pkwy.       Fax: (510) 426-8951
support@livingston.com Pleasanton, CA 94566      http://www.livingston.com