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/>