For an Adobe Acrobat format version of the Point-to-Point Protocol Trace graphic, click here.

The PPP trace depicted in "Point-to-Point Protocol Trace" shows a trace between a client PC and an Ascend MAX located at an ISP. At the bottom of the Conf-Req from the ISP is a type option, Multilink-Endpoint-Discriminator, which is used to configure Multilink PPP. Our PC wasn't configured for Multilink PPP, so we sent a Config-Rej (Frame 4). The ISP sent a new Conf-Req without the Multilink-Endpoint-Discriminator (Frame 5), which drew a Conf-Ack reply (Frame 6), and the ISP to PC side is negotiated.

Common Problems LCP sets up the link for NCPs. But if LCP fails to converge, nothing happens. Typical miscues include failed authentication, authentication protocol mismatch and possibly bad scripting on the client PC. Unfortunately, some Internet dialers don't accurately report the reasons for a link failure. First, make sure your password is correct. If the password isn't the problem, an authentication protocol mismatch is likely.

Authentication protocol mismatches can be tough to trace because they often tell users they failed to authenticate, leading the user to suspect an incorrect user name/password. A classic case is an attempt to log in to a Windows NT server using CHAP. Unlike PAP (Password Authentication Protocol), which sends the user name/password pair in the clear, CHAP sends the user name and an encrypted string, using the MD5 hash algorithm, for authentication.

The problem in using CHAP with older PPP dialers and Windows NT 4.0 RAS is that NT uses an MD4 hash to store its user passwords, which can't be recovered. Plus, Microsoft used the same protocol ID (C223) for its implementation of CHAP with an algorithm field set to 80 denoting MD4 (MD5 is denoted with the algorithm field set to 05). Older PPP dialers skip the algorithm field and return the challenge using an MD5 hash. The only way to identify the problem is to use a PPP decode.

In the PPP logs, much of the PPP traffic is hidden from view--negotiations are reduced to statements about what is received and acknowledged from the client's point of view. These statements provide enough information to begin solving connection failures. Where the client is configured to use CHAP and the remote-access server used PAP, Windows95/98 doesn't tell you much in the dialog. Examine the PPP log and you'll find the client is sending Conf-Nak's to the PAP protocol. Many of the PPP options show up in the logs, though you'll need to read the lines carefully to make sense of the negotiation.

Adding the network protocols after authenticating to the remote-access server using PAP (note the Authentication-Protocol type in the trace), we began negotiating NCPs such as IPCP and CCP (Compression Control Protocol). A number of NCPs may be negotiated over PPP. If you were dialing into a remote-access server on your corporate network, you could also negotiate other protocols, such as IPXCP and ARA. Debugging NCP protocols is more complex due to Layer 3 addressing and configuration issues.

The common problems with NCP are misconfigured clients, failure to negotiate compression and routing on the client. Cryptic messages on the dial-up clients, such as Message 645 in Win98, don't help in debugging. Message 645 is used for both failed authentication and misconfigured network protocols. To see what is being negotiated, you need to see what is being passed for NCP. Start with the logs from the PPP dialers.

To track protocol negotiations in Win95/98 or the MacOS, look for lines containing IPCP. IPCP negotiation begins with the first packet and continues until the log indicates the layer is "up" (in Windows) or "PPP is ready for IP" (in MacOS). The messages are somewhat cryptic and at a fairly high level; much of the packet-by-packet negotiation is hidden. Both systems log only what is received and accepted from the other side's Conf-Req.

These protocols need to be set up properly in both the client and the server for the protocol to work over PPP. Luckily, the NCPs are negotiated separately, so if one protocol fails to negotiate, the others will still work. IPXCP and CCP may not be widely supported. In Win95, you can open the dial-up networking tab and see which network protocols have been negotiated, but you can't tell which protocol was used for authentication nor if your connection is compressed; Win98 tells you how you authenticated, what the protocol is and whether your connection is compressed. But if you are not getting the protocols set up, it helps to see who is dropping the negotiation. There is one more PPP message of importance: Protocol Reject. Its sender tells the peer that the sender doesn't understand the protocol; the peer must stop trying to configure it.

For example, if the client is set up to negotiate IPX and the server only negotiates IP, the server will send Protocol Reject for IPX. NCP negotiation runs into trouble with older or poorly implemented PPP stacks on both clients and servers. Instead of sending a Protocol Reject, the server or client may try to negotiate the protocol until the end user drops the link. During IPCP, for instance, more recent remote-access servers will try to negotiate VJ compression. If the client is older, it may not recognize the VJ Compression option and ignores it, so IPCP never converges. The client gets an IP address, and data can be sent in one direction, but IPCP will be reset with each subsequent attempt to negotiate IPCP with VJ Compression.

CCP is a framework for negotiating compression on a PPP link. Several protocols use CCP, such as STAC LZS, Microsoft Point-to-Point Compression (MPPC) and GandalfFZA. Many compression protocols can be offered during CCP negotiations, though only one is chosen. A remote-access server might send a Conf-Req for STACLZS, and receive a Conf-Nak requesting MPPC instead. The process continues until compression is negotiated. If either side doesn't understand CCP, a Protocol Reject is sent. Some client and server implementations may not recognize CCP, causing the sender to continue offering CCP during the life of the connection.

Tools of the Trade We relied on several tools during our remote-access testing; see "The Right Tool for the Job: PPP Analyzers Help Debug Remote Access" (www.networkcomputing.com/915/915r2. html) for a roundup.

Information is the key to successful networking, and to that end we recommend you take a look at a few PPP documents. The PPP draft is available at info.internet.isi.edu:80/in-notes/rfc/files/ rfc1661.txt; see the PPP extensions at www.ietf.org/html.charters/pppext-charter. html. While these documents are aimed at developers, the first few chapters contain valuable information about the problem spaces the various protocols are designed to address.

Send comments on this article to Mike Fratto at mfratto@nwc.com.