PPP Decoding Primer
This appendix covers these topics:
Overview
Many of the diagnostic commands display raw data. This Primer is designed to assist you in decoding PPP, MP, MP+ and BACP negotiations. The negotiations can be logged with the Diagnostic commandsPPPDump,WANDisplay, WANDSess, WANNext orWANOpen. For more detailed information than this guide provides, refer to specific RFCs. A partial list of pertinent RFCs appears at the end of this guide.
Breaking down the raw data
An important concept to keep in mind is that each device negotiates PPP independently, so the options might be identical for each direction of the session.FF 03indicating it is a PPP frame.- A two-byte Protocol Identifier.
- A one-byte Packet Format ID number
- A one-byte ID number.
- A two-byte length.
- Options for the protocol.
Following are the packet formats:
Note: If a packet received from the wan fails the Cyclic Redundancy Check (CRC) the display is similar to the following, where
RBAD denotes Received BAD:
RBAD-27:: 8712 octets @ 26CFE8 [0000]: fe dd dd dd dd dd dd dd dd dd dd dd dd dd dd dd [0010]: dd dd dd dd dd dd dd dd dd dd dd dd dd dd dd dd [0020]: dd dd dd dd dd dd dd dd dd dd dd dd dd dd dd dd [0030]: dd dd dd dd dd dd dd dd dd dd dd dd dd dd dd dd
Annotated Traces
Use the following traces as guides to help you decode other traces.XMIT-3:: 29 octets @ 2C2E94 [0000]: ff 03 c0 21 01 01 00 19 00 04 00 00 01 04 05 f4 [0010]: 11 04 05 f4 13 09 03 00 c0 7b 4c e0 4cThis is a second LCP Configure Request from the same device. Everything in the packet is identical to the previous packet, except the ID number has incremented from 01 to 02:
XMIT-3:: 29 octets @ 2C2E94 [0000]: ff 03 c0 21 01 02 00 19 00 04 00 00 01 04 05 f4 [0010]: 11 04 05 f4 13 09 03 00 c0 7b 4c e0 4cLCP Configure Request - CHAP authentication, Magic number
RECV-3:: 19 octets @ 2BEB8C [0000]: ff 03 c0 21 01 60 00 0f 03 05 c2 23 05 05 06 4e [0010]: 36 c9 05LCP Configure Acknowledgment - This device will authenticate using CHAP. The Magic number is also acknowledged:
XMIT-3:: 19 octets @ 2C2E94 [0000]: ff 03 c0 21 02 60 00 0f 03 05 c2 23 05 05 06 4e [0010]: 36 c9 05LCP Configure Reject - MP+, MRU of 1524, MRRU of 1524 and End Point Discriminator.
RECV-3:: 29 octets @ 2BF1A4 [0000]: ff 03 c0 21 04 02 00 19 00 04 00 00 01 04 05 f4 [0010]: 11 04 05 f4 13 09 03 00 c0 7b 4c e0 4cLCP Configure Request - Note all values that were previously rejected are no longer in the packet:
XMIT-3:: 8 octets @ 2C2E94 [0000]: ff 03 c0 21 01 04 00 04LCP Configure Acknowledgment -
RECV-3:: 8 octets @ 2BF7BC [0000]: ff 03 c0 21 02 04 00 04At this point, since both sides have transmitted LCP Configure Acknowledgments, LCP is up and the negotiation moves to the authentication phase.
This device receives a CHAP challenge from the remote end:
RECV-3:: 21 octets @ 2BFDD4 [0000]: ff 03 c2 23 01 01 00 11 04 4e 36 c9 5e 63 6c 63 [0010]: 72 34 30 30 30This device transmits its encrypted user name and password:
XMIT-3:: 36 octets @ 2C2E94 [0000]: ff 03 c2 23 02 01 00 20 10 49 b8 e8 54 76 3c 4a [0010]: 6f 30 16 4e c0 6b 38 ed b9 4c 26 48 5f 53 65 61 [0020]: 74 74 6c 65The remote device sends a CHAP Acknowledgment:
RECV-3:: 8 octets @ 2C03EC [0000]: ff 03 c2 23 03 01 00 04At this point, the negotiation moves from authentication to negotiation of Network Control Protocols (NCPs). Ascend supports Bridging Control Protocol (BCP), IPCP, IPXCP and ATCP.
IPCP Configure Request - Van Jacobsen Header Compression, IP address of 1.1.1.1
RECV-3:: 20 octets @ 2C0A04 [0000]: ff 03 80 21 01 e3 00 10 02 06 00 2d 0f 00 03 06 [0010]: 01 01 01 01BCP Configure Request -
RECV-3:: 8 octets @ 2C101C [0000]: ff 03 80 31 01 55 00 04IPCP Configure Request - IP address of 2.2.2.2
XMIT-3:: 14 octets @ 2C2E94 [0000]: ff 03 80 21 01 01 00 0a 03 06 02 02 02 02IPCP Configure Reject - Van Jacobsen Header Compression. The remote device should send another IPCP Configure Request and remove the request to do VJ Header Compression:
XMIT-3:: 14 octets @ 2C2E94 [0000]: ff 03 80 21 04 e3 00 0a 02 06 00 2d 0f 00BCP - Protocol Reject. This local device is not configured to support bridging.
XMIT-3:: 8 octets @ 2C2E94 [0000]: ff 03 80 31 08 55 00 04IPCP Configure Acknowledgment
RECV-3:: 14 octets @ 2C1634 [0000]: ff 03 80 21 02 01 00 0a 03 06 01 01 01 01IPCP Configure Request - Note VJ Header Compression is not requested this time.
RECV-3:: 14 octets @ 2C1C4C [0000]: ff 03 80 21 01 e4 00 0a 03 06 02 02 02 02IPCP Configure Acknowledgment
XMIT-3:: 14 octets @ 2C2E94 [0000]: ff 03 80 21 02 e4 00 0a 03 06 01 01 01 01At this point, a PPP connection has been successfully negotiated. The caller was successfully authenticated by means of CHAP and IPCP was the only successfully configured NCP. IPX, Appletalk and bridging will not be supported during this session.
Below are two packets used in determining link quality:
RECV-3:: 16 octets @ 2BEB8C [0000]: ff 03 c0 21 09 01 00 0c 4e 36 c9 05 00 00 00 00LCP Echo Response
XMIT-3:: 16 octets @ 2C2E94 [0000]: ff 03 c0 21 0a 01 00 0c 00 00 00 00 00 00 00 00
Example of MP+ call negotiation
LCP Configuration Request - MP+, MRU of 1524, MRRU of 1524, End Point Discriminator using the device's MAC address:XMIT-31:: 29 octets @ D803C [0000]: ff 03 c0 21 01 01 00 19 00 04 00 00 01 04 05 f4 [0010]: 11 04 05 f4 13 09 03 00 c0 7b 5c d3 71LCP Configure Request - MP+, MRU of 1524, PAP authentication is required. MRRU of 1524, End Point Discriminator using the device's MAC address:
RECV-31:: 33 octets @ D4FBC [0000]: ff 03 c0 21 01 01 00 1d 00 04 00 00 01 04 05 f4 [0010]: 03 04 c0 23 11 04 05 f4 13 09 03 00 c0 7b 53 f0 [0020]: 7aLCP Configuration Acknowledgment -
RECV-31:: 29 octets @ D55CC [0000]: ff 03 c0 21 02 01 00 19 00 04 00 00 01 04 05 f4 [0010]: 11 04 05 f4 13 09 03 00 c0 7b 5c d3 71LCP Configuration Acknowledgment -
XMIT-31:: 33 octets @ D803C [0000]: ff 03 c0 21 02 01 00 1d 00 04 00 00 01 04 05 f4 [0010]: 03 04 c0 23 11 04 05 f4 13 09 03 00 c0 7b 53 f0 [0020]: 7aAt this point, LCP is up. Next is the authentication phase. The local device agreed to authenticate using PAP, so it should transmit its user name and password. Note that it is not encrypted, and user name and password can be decoded very easily:
XMIT-31:: 20 octets @ D803C [0000]: ff 03 c0 23 01 01 00 10 06 6a 73 6d 69 74 68 03 72 [0010]: 65 64PAP Authentication Acknowledgment -
RECV-31:: 9 octets @ D5BDC [0000]: ff 03 c0 23 02 01 00 05 00Authentication is successful. Final negotiation determines protocols to be supported over the link.
Note: MP+ was negotiated, and both devices begin sending MP+ packets from here. The data portion of the packet is identical to PPP, but there is an 8-byte MP+ header instead of the 2- byte PPP header:
Next, the 80 31 01 designates this as a BCP Configure Request:
RECV-31:: 20 octets @ D61EC [0000]: ff 03 00 3d c0 00 00 00 80 31 01 01 00 0a 03 03 [0010]: 01 07 03 00BCP Configure Request:
XMIT-31:: 20 octets @ D803C [0000]: ff 03 00 3d c0 00 00 00 80 31 01 01 00 0a 03 03 [0010]: 01 07 03 00BCP Configure Acknowledgment:
XMIT-31:: 20 octets @ D864C [0000]: ff 03 00 3d c0 00 00 01 80 31 02 01 00 0a 03 03 [0010]: 01 07 03 00BCP Configure Acknowledgment:
RECV-31:: 20 octets @ D67FC [0000]: ff 03 00 3d c0 00 00 01 80 31 02 01 00 0a 03 03 [0010]: 01 07 03 00BCP is up and the session begins sending bridged traffic. No routed protocols were negotiated.
RECV-31:: 8 octets @ D5BDC [0000]: ff 03 00 3d c0 00 00 05 XMIT-31:: 8 octets @ D803C [0000]: ff 03 00 3d c0 00 00 04 RECV-31:: 8 octets @ D61EC [0000]: ff 03 00 3d c0 00 00 06 XMIT-31:: 8 octets @ D803C [0000]: ff 03 00 3d c0 00 00 05The following RFCs provide more detail about the subjects listed in their titles:
4175
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
