RE: (PM) ascend p15 to pm3

James Courtier-Dutton (dutton@livingston-ent.co.uk)
Tue, 9 Mar 1999 09:14:40 -0000

Hello James
The reason this negotiation goes wrong is that the ascend P15 is replying
with a faulty NAK.
The purpose of a NAK is so the P15 can tell the PM3 that it does not like
the MRRU value.
In the NAK the P15 should suggest a value it would like.
As the P15 is replying with a NAK containing a value it does not like, the
PM3 is assuming that the value in the NAK is what the P15 wants, and duly
puts it in the next request.
Thus you have a loop.
I would go searching for a code update for the P15, so that it fixes its
faulty NAK.
Cheers
James

> -----Original Message-----
> From: owner-portmaster-users@livingston.com
> [mailto:owner-portmaster-users@livingston.com]On Behalf Of James
> Sneeringer
> Sent: Wednesday, March 03, 1999 04:46
> To: portmaster-users@livingston.com
> Subject: (PM) ascend p15 to pm3
>
>
> Us: PM-3A-2T, PRI, DMS-100, ComOS 3.8.2
> Them: Ascend Pipeline 15, NI-1, firmware 1.1.0/b1.p15
>
> Has anyone ever managed to coax one of these things into connecting to a
> PM3 using MP? The user swears up and down that it isn't set for MP+. It
> will connect with PPP (single channel), but with MP, it fails to negotiate
> LCP, and eventually bails out. Specifically, the P15 and the PM3 appear
> to be arguing over the MRRU value (see below).
>
> I found some posts about it in the list archives from 1997, where someone
> appeared to have the same problem, but no resolution was ever posted.
>
> Here's the complete PPP debugging (0x51) output:
>
> --------------------------------------------------------------------------
> Received LCP_CONFIGURE_REQUEST on port S20 of 21 bytes containing:
> 01 02 00 19 01 04 05 F4 11 04 05 F4 13 0D 01 42 75 66 66
> 65 72 00 6F 00 BC
> Packet Info: Code: 0x01, ID: 0x02, 25 bytes.
> Maximum-Receive-Unit [0x01], length: (4 bytes) 1524 bytes [0x05F4]
> Multilink-MRRU [0x11], length: (4 bytes), [0x05F4]
> Max-Receive-Reconstructed-Unit (MRRU): 1524 bytes.
> Multilink-Endpoint-Discriminator [0x13], length: (13 bytes),
> [0x01427566666572006F00BC]
> Class [0x01]: Locally Assigned Address 66.117.102.102
>
> Sending LCP_CONFIGURE_REQUEST to port S20 of 29 bytes containing:
> 01 05 00 1D 05 06 32 F4 0C 13 03 04 C0 23 11 04 06 1C 12
> 02 13 09 03 00 C0 05 04 13 BA
> Packet Info: Code: 0x01, ID: 0x05, 29 bytes.
> Magic-Number [0x05], length: (6 bytes), [0x32F40C13]
> Authentication-Protocol [0x03], length: (4 bytes), Password
> Authentication Protocol [0xC023]
> Multilink-MRRU [0x11], length: (4 bytes), [0x061C]
> Max-Receive-Reconstructed-Unit (MRRU): 1564 bytes.
> Multilink-Short-Sequence-Number-Header [0x12], length: (2 bytes)
> Multilink-Endpoint-Discriminator [0x13], length: (9 bytes),
> [0x0300C0050413BA]
> Class [0x03]: IEEE 802.1 MAC Address 00 C0 05 04 13 BA
>
> Sending LCP_CONFIGURE_ACK to port S20 of 25 bytes containing:
> 02 02 00 19 01 04 05 F4 11 04 05 F4 13 0D 01 42 75 66 66
> 65 72 00 6F 00 BC
> Packet Info: Code: 0x02, ID: 0x02, 25 bytes.
> Maximum-Receive-Unit [0x01], length: (4 bytes) 1524 bytes [0x05F4]
> Multilink-MRRU [0x11], length: (4 bytes), [0x05F4]
> Max-Receive-Reconstructed-Unit (MRRU): 1524 bytes.
> Multilink-Endpoint-Discriminator [0x13], length: (13 bytes),
> [0x01427566666572006F00BC]
> Class [0x01]: Locally Assigned Address 66.117.102.102
>
> Received LCP_CONFIGURE_REJECT on port S20 of 8 bytes containing:
> 04 05 00 0C 05 06 32 F4 0C 13 12 02
> Packet Info: Code: 0x04, ID: 0x05, 12 bytes.
> Magic-Number [0x05], length: (6 bytes), [0x32F40C13]
> Multilink-Short-Sequence-Number-Header [0x12], length: (2 bytes)
>
> Sending LCP_CONFIGURE_REQUEST to port S20 of 21 bytes containing:
> 01 06 00 15 03 04 C0 23 11 04 06 1C 13 09 03 00 C0 05 04
> 13 BA
> Packet Info: Code: 0x01, ID: 0x06, 21 bytes.
> Authentication-Protocol [0x03], length: (4 bytes), Password
> Authentication Protocol [0xC023]
> Multilink-MRRU [0x11], length: (4 bytes), [0x061C]
> Max-Receive-Reconstructed-Unit (MRRU): 1564 bytes.
> Multilink-Endpoint-Discriminator [0x13], length: (9 bytes),
> [0x0300C0050413BA]
> Class [0x03]: IEEE 802.1 MAC Address 00 C0 05 04 13 BA
>
> Received LCP_CONFIGURE_NAK on port S20 of 4 bytes containing:
> 03 06 00 08 11 04 06 1C
> Packet Info: Code: 0x03, ID: 0x06, 8 bytes.
> Multilink-MRRU [0x11], length: (4 bytes), [0x061C]
> Max-Receive-Reconstructed-Unit (MRRU): 1564 bytes.
> --------------------------------------------------------------------------
>
> They get into a deadly embrace with this last REQUEST-NAK pair; we keep
> REQUESTing, they keep NAKing, indefinitely. What's curious is that
> further back, the PM3 ACK'd their requested MRRU value of 1524, but
> evidently didn't remember this, and subsequently asked for an MRRU of 1564
> again, which the P15 now NAKs.
>
> If anyone has any suggestions, I would be very happy to hear them.
>
> -James
>
> --
> James Sneeringer <jvs@ocslink.com> (309) 687-5465
> System Administrator (800) 382-7415
> Oberlander Communications Systems, Inc.
> http://www.oberlander.com/
> an Alliance Internet Technologies, LLC
> partner http://www.allianceit.net/
>
>
> -
> To unsubscribe, email 'majordomo@livingston.com' with
> 'unsubscribe portmaster-users' in the body of the message.
> Searchable list archive: <URL:http://www.livingston.com/Tech/archive/>
>

-
To unsubscribe, email 'majordomo@livingston.com' with
'unsubscribe portmaster-users' in the body of the message.
Searchable list archive: <URL:http://www.livingston.com/Tech/archive/>