How to Interpret the Ppplog.txt File

• Microsoft Windows 95

SUMMARY

This article describes how to interpret the Ppplog.txt file. It also provides information about background concepts used in the development of the Point-to-Point protocol (PPP) and its peripheral components.

References to an IETF Request-for-Comments (RFC) can be followed by locating the RFC, by number, at the following Web site:

   http://ds.internic.net/ds/rfc-index.html

Notes

• Excerpts from Ppplog.txt files in this article have been edited for readability. Specifically, the date stamp has been removed and the time stamp has been reduced to the format [seconds.tenths-of-a- second]. Comments are at the bottom of each listing. For the sake of brevity, unnecessary lines may have been removed. Where this has been done, ellipses have been placed between the line numbers.
• The term "peer(s)" is used in this article to describe either or both computers involved in a connection.

MORE INFORMATION

Enabling Ppplog.txt File Generation

The Ppplog.txt file is generated by Pppmac.vxd, also known as the Dial-Up Adapter. The file is appended each time the Dial-Up Adapter is used. To enable the generation of a Ppplog.txt file, follow these steps:

1. In Control Panel, double-click Network.

2. On the Configuration tab, double-click the Dial-Up Adapter.

3. Click the Advanced tab.

4. In the Property box, click Record A Log File.

5. In the Value box, click Yes.

6. Click OK or Close until you return to Control Panel. When you are prompted to restart your computer, do so.

Frame and Packet Structure

The structures are listed in OSI model order, from the data-link layer up. Individual protocol structures are not included; that level of complexity exceeds the scope and purpose of this article. A complete HDLC-framed PPP packet has the following structure:

   [-Flag-|-Address-|-Control-|-Protocol-|-Information-|-Padding-|-FCS-|-
   Flag-]

HDLC Framing of PPP Data:

   [-Flag-|-Address-|-Control-|-PPP Encapsulation-|-FCS-|-Flag-]

Because PPP deals with point-to-point connections, the majority of implementations do not support individual addressing of PPP frames. The address that is used and must be supported by all implementations of PPP is the All-Stations broadcast address: 11111111 (0xff).

The Control field is a single octet in length and, unless negotiated otherwise, has the value 00000011 (0x03).

PPP Encapsulation is covered below.

The Frame Check Sequence (FCS) is the checksum for the frame. It can be two or four octets (16- or 32-bit value) in length. The FCS defaults to the 16-bit value. It is calculated using the Address, Control, Protocol, Information, and Padding fields. Excluded are bits or octets inserted at the physical layer for transmission (synchronous or asynchronous) framing purposes, the FCS and Flag fields, and any bits that are flagged for transparent transmission in the Asynchronous Control Character Map (the ACCM is described later in this article).

PPP Encapsulation:

   [-Protocol-|-Information-|-Padding-]

The Information field consists of zero or more octets, which, including padding octets, does not exceed the Maximum Receivable Unit (MRU) length negotiated for the connection.

The Padding field is optional, and any data used as padding must be easily discernible as such by the peers. If padding data is included, and exceeds the MRU, it is discarded silently.

Control Mechanisms

In order to properly interpret the Ppplog.txt file, read the following section to familiarize yourself with PPP's underlying control mechanisms and the phases the connection passes through.

Finite-State Automaton (FSA)

The FSA processes status messages from different layers, and then, after evaluating the message, tells other layers what they should do next. In general, the FSA relates information from layer to layer, without actually interacting in the exchange of data. For example, if the physical layer (modem-to-modem connection) is interrupted, the FSA notifies the network layer that it can no longer function, and must shut down. The automaton is said to exist in "states." The progress of the connection is dependent on the current state of the automaton.

Link Control Protocol (LCP)

The link control protocol's job is to manage the data-link layer. It sets up, configures, and tests the connection. There are three classes of LCP packets:

1. Link Configuration packets establish and configure the link.

2. Link Termination packets terminate the link.

3. Link Maintenance packets manage and test the link.

Network Control Protocol (NCP)

An NCP is a "protocol manager." Each protocol that is used in the connection has an NCP. They work with the LCP to get the protocols up and ready to be used. When an NCP has opened, it is possible for network-layer traffic to be carried by the protocol that the NCP configured. NCPs are not defined in the same RFC as the Point-to-Point protocol. They are defined separately, and as such are not covered in detail in this article.

Phase Breakdown

A PPP session consists of five distinct phases. Ppplog.txt file entries are more readily understood based on what happens during these phases. When common failures in a phase in Windows 95 are referenced, any existing Microsoft Knowledge Base articles about that failure are referred to.

Link-Dead

Every PPP connection starts in the Link-Dead condition. In this condition, the physical layer is said to be "Down," and the FSA "Closed." In a switched circuit such as a modem connection over a telephone line, this condition exists when the modems are not connected. In a continuous connection, such as a leased line, there is usually some mechanism in place that enables the hardware to signal PPP that the link is available. When a carrier has been negotiated or the connection established, the hardware-handling routines signal the FSA that they can carry traffic, and PPP moves on to the Link Establishment phase.

Link Establishment

In the Link Establishment phase, the LCP configures and establishes the data-link layer. Its aim is to provide a solid foundation on top of which the network layer can operate. This process primarily involves the exchange of Class 1 LCP packets, and starts when one peer receives a Configure-Request packet from another. When all configuration options have been negotiated, a Configure-Ack packet is returned to the peer that initiated negotiation. At this point, the layer is up and PPP can proceed to the next phase.

The following example illustrates a hypothetical conversation between two peers, Peer1 and Peer2. Each line represents a packet being transmitted. The peer sending the packet is listed in parentheses, and the packet type is listed in brackets. When the peer sending the packet is noted as "PeerN(a,b,c)," a possible response to a request is being noted, not sequential packets from the same peer.

Synopsis:

 (Peer1)-[Configure-Request]: Contains information about all configuration
 options to be negotiated. All options are negotiated simultaneously.

 (Peer2a)-[Configure-Ack]: If the peer receiving the Configure-Request
 accepts all configuration options, it returns a Configure-Ack. Receipt of
 a Configure- Ack signals the end of LCP configuration.

 (Peer2b)-[Configure-Nak]: If the peer receiving the Configure-Request
 accepts all of the configuration option fields but not all the values of
 the fields, it must send a Configure-Nak. The Configure-Nak packet
 specifies which option field values were not acceptable and suggests
 changes to the peer.

 (Peer2c)-[Configure-Reject]: Indicates to the peer that some of the
 option fields requested for negotiation are unrecognizable or
 unacceptable. The peer must send a new Configure-Request, omitting
 the rejected option fields.

 (Peer1)-[Configure-Request]
 .
 .
 .
 (Peer2)-[Configure-Ack]

 (Link configuration complete)

 Asynchronous Control Character Map
 Magic Number
 Address and Control Field Compression
 Protocol Field Compression

Authentication

When the link has been configured, the FSA changes state to "Opened." The next step for the PPP connection is the Authentication phase. If a client fails to successfully authenticate itself, or if the host cannot authenticate the client for some reason, the connection is terminated.

Usually, failure at this stage is due to an incorrect user name, password, logon domain, or preferred server entry. If this is the case, a User Logon dialog box is displayed, prompting for the correct information. For additional information about this dialog box, see the following article in the Microsoft Knowledge Base:

   ARTICLE-ID: Q148899
   TITLE     : Dial-Up Networking Dialog Box Prompts for Domain Name

Network Layer Configuration

After successful authentication, the last step is to configure and open all network protocols that have been selected on each peer. The NCP for a given network-layer protocol takes care of any configuration options that need to be negotiated. When option negotiation is finished, the protocol is opened and can begin carrying network-layer traffic. If one peer is not configured to use a protocol that the other peer is attempting to use, it returns the packet in a Protocol-Reject. A Protocol-Reject is a Class 3 LCP packet. The message shown in the Ppplog.txt file when a Protocol- Reject is sent or received is covered in the "Parsing the Ppplog.txt File" section of this article. Upon receipt of a Protocol-Reject packet, the peer must stop using the protocol contained within the packet. In Windows 95, if both sides reject all protocols, a dialog box is displayed indicating that this situation has occurred. For additional information about this dialog box, see the following article in the Microsoft Knowledge Base:

   ARTICLE-ID: Q130079
   TITLE     : Dial-Up Networking Could Not Negotiate Compatible...

Synopsis:

 (Peer1)-[8021 NCP packet]: Peer1 transmits a packet over the link
 containing the Internet Protocol Control Protocol (PPP ID# 8021).

 (Peer2)-<receives packet>: Peer2 receives the packet, and upon inspection
 of the protocol identifier field, does not recognize the protocol being
 used. In Windows 95, this translates into one of the following three
 scenarios: the protocol is disabled in the connectoid, the protocol is
 not bound to the Dial-Up Adapter, or the protocol is not loaded on the
 computer. The message generated in the Ppplog.txt file is covered later.

 (Peer2)-[Protocol-Reject]: Peer2 encapsulates a stripped-down version of
 the unsupported packet inside a Protocol-Reject packet, and returns it to
 Peer1.

 (Peer1)-[Protocol-Reject]: Peer1 receives the Protocol-Reject, and upon
 inspection of the protocol identifier field, immediately shuts down the
 protocol.

 (Protocol-Reject complete)

Link Termination

Link Termination can be caused by a number of events. These events include, but are not limited to: link failure (loss of carrier), authentication failure, and failure to negotiate at least one network protocol. Link Termination is affected by the exchange of Class 2 LCP packets. When the link begins the process of closing down, the network layer is notified that physical transport services are about to become nonexistent. Any non-LCP packets received during this time are discarded. When both sides have disconnected, PPP returns to the Link-Dead phase.

Synopsis:

 (Peer1)-[Terminate-Request]: When one peer wants to close the connection
 it can send a Terminate-Request.

 (Peer2)-[Terminate-Ack]: Upon reception of a Terminate-Request, a peer
 must respond with a Terminate-Ack.

 (Connection closed)

Parsing the Ppplog.txt File

The following sections are divided into loosely categorized groupings of messages. They are not necessarily listed in order of appearance, and a message listed here may not appear in every Ppplog.txt file.

State Transition Messages

Messages that indicate a layer's transition from one state to another appear frequently, and occur in several forms: Started, Up, Down, and Finished. The message can be prefixed and suffixed with information detailing its origin and what particular part of the session it is reporting about.

NOTE: The status messages described below use the following conventions for describing variables that may change in different instances of the message:

• "aaa" is an abbreviation or acronym referring to the source of the message.
• CHAP: acronym for Challenge-Handshake Authentication Protocol
• PAP: acronym for Password Authentication Protocol
• ND: acronym for No Description, this is the Shiva-PAP (SPAP)

This message, when prefixed with:

• LCP: Indicates the beginning of configuration option negotiation.
• CHAP, PAP, or ND: Indicates the beginning of user authentication.
• NCP: Indicates that the NCP for a particular network-layer protocol has begun configuration negotiation.

This message, when prefixed with:

• LCP: Indicates the completion of configuration option negotiation.
• CHAP, PAP, or ND: Indicates that the user logged on successfully.
• NCP: Indicates that the protocol's negotiation options were successfully negotiated with the peer.

This message, when prefixed with:

• LCP: Indicates that a Terminate-Request packet has been received and acknowledged.
• CHAP, PAP, or ND: Is displayed as a formality, all protocols are closed when the link is being terminated.
• NCP: Indicates that the network-layer activity of this protocol has been stopped, usually due to link termination.

This message, when prefixed with:

• LCP: Indicates that the link has proceeded to the Link-Dead phase.
• NCP: Indicates that the NCP has completely ceased operation.

Static Status Messages

Static messages appear in every Ppplog.txt file, at the beginning of each new addition to the log file. They serve little purpose other than to provide a familiar point of reference when you are trying to distinguish where one session starts and another ends.

NOTE: The status messages described below may use the following conventions for describing variables that may change in different instances of the message:

• "aaaa" is an acronym for the server type.
• "bbbb" is a friendly name for the server type.

This line is the first line in the Ppplog.txt file. It is written when the file is opened, and control of the connection is handed to Pppmac.vxd from TAPI.

No Installable CP VxDs Are Loaded:

The architecture of Pppmac.vxd allows for installable Control Protocols to be added in the form of a virtual device driver (VxD). Windows 95 includes only one: Spap.vxd. In addition, the following registry key contains the list of installable VxDs currently in use on the computer:

   HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\PPP\CPList

Installable CP VxD SPAP Is Loaded:

This line indicates that the Shiva Password Authentication Protocol has been loaded.

Server Type Is aaaa (bbbb):

This message displays the type of connection being attempted. Note that although all of the following server types listed are supported by the Windows95 Dial-Up Networking client, Dial-Up Networking Server accepts only RAS and PPP connections:

• RAS: Remote Access Server
• PPP: Point-to-Point protocol
• NRN: NetWare Connect (version 1.0 only)
• SLIP: Serial Line Internet protocol
• CSLIP: Compressed SLIP (uses Van Jacobson IP header compression)

To install the Dial-Up Scripting tool, follow these steps:

1. In Control Panel, double-click Add/Remove Programs.

2. On the Windows Setup tab, click Have Disk.

3. In the Copy Manufacturer's Files From box, type the following line and then click OK

         <drive>:\admin\apptools\dscript
   

   where <drive> is the CD-ROM drive containing the Windows 95 CD-ROM.

4. Click OK.

5. Click "SLIP and Scripting for Dial-Up Networking."

6. Click Install.

   ARTICLE-ID: Q135315
   TITLE     : CD-ROM Extras for Microsoft Windows 95 Upgrade

Dynamic Status Messages (FSA)

Messages prefixed with "FSA :" report information about the status of the connection.

NOTE: The status messages described below use the following conventions for describing variables that may change in different instances of the message:

• "xx" is an 8-bit hexadecimal value.
• "xxyy" is a 16-bit hexadecimal value that identifies a protocol.
• "nnnn" is an abbreviated name for protocol xxyy.

This message indicates that an NCP that is supported by the implementation of PPP has been selected in the connectoid for this connection.

Protocol Disabled by User - Skipping Control Protocol xxyy (nnnn):

This message indicates that a protocol that is supported by the implementation of PPP has been disabled by the user in the Server Types dialog box in the Dial-Up Networking connectoid.

Protocol Not Bound - Skipping Control Protocol xxyy (nnnn):

This message indicates that a protocol that is supported by the implementation of PPP is not bound to the Dial-Up Adapter in the Network tool in Control Panel.

Encrypted Password Required:

This message indicates that both peers have the ability to exchange an encrypted password, and the option is enabled at both ends of the connection. When applied to Windows 95, this message indicates that the client has enabled the Require Encrypted Password option in the Server Types Settings dialog box, and the DUN server has the same option enabled in its Server Types Settings dialog box. When only one is enabled, the setting is ignored. It does not affect the outcome of the connection.

Sending Protocol Reject for Control Protocol xxyy:

This message is direction-specific. It indicates that the computer on which the Ppplog.txt file is currently being examined has sent a Protocol- eject packet for a specific network-layer protocol that the implementation does not support. The packet contains, among other things, a field that contains the 16-bit protocol identifier and a field that contains as much information from the rejected packet as possible up to the session's Maximum-Receivable Unit (MRU) length.

Received Protocol Reject for Control Protocol xxyy:

This message is direction-specific. It indicates that the computer on which the Ppplog.txt file is currently being examined has received a Protocol-Reject for an NCP whose use it is attempting to negotiate with a peer.

Remote PPP Software Sent Unrecognized Packet of Type xx to CP xxyy!:

This message follows immediately after the message "Received unknown code nn" described later in this article. It indicates the packet type identifier of an unrecognized packet and the control protocol named in the protocol type field. This usually indicates a faulty physical connection such as a misconfigured modem, not a malfunctioning implementation of PPP.

Last Control Protocol Is Up:

This message indicates that the last control protocol loaded by PPP has changed to the "Up" state. This does not necessarily mean that the connection will be successful.

Last Control Protocol Failed:

This message indicates that the last control protocol selected for use with the PPP session has failed to change to the "Up" state. This does not necessarily mean that the connection will fail.

No Network Protocols Were Successfully Negotiated:

This message usually follows the one above. The "Dial-Up Networking could not negotiate a compatible set of network protocols..." error message displayed by Dial-Up Networking is generated when this condition exists. Stepping backward from this message through the Ppplog.txt file will show you which computer rejected which protocol, and can aid in determining which computer has a problem.

Dynamic Status Messages (LCP)

Messages prefixed with "LCP :" report LCP event information. These events usually consist of option negotiation status messages or layer transition notifications.

NOTE: The status messages described below use the following conventions for describing variables that may change in different instances of the message:

• "nn" is a decimal number.
• "xxxx" is a decimal number indicating a quantity in bytes.
• "xxyy" is a 16-bit hexadecimal value that identifies a protocol.
• "nnnn" is a semi-friendly abbreviated name for the same protocol.

This message indicates that the peers have agreed on an ACCM of yyyyy. The ACCM is the Asynchronous Control Character Map. It can range in length from one to four octets. Its function is to provide a method for making control characters, which could be misinterpreted as actual data, transparent in the data stream. The default value for the ACCM is 0xffffffff, although 0xa0000 is most commonly seen with Windows 95. If you want to determine which characters are being mapped into the ACCM, convert it to binary, and then locate the positions of all bits set to 1. For example:

 ACCM = a0000h or 0000101000000000b

 0 0 0 0 1 0 1 0 0 0 0 0 0 0 0 0
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

 Hex 0x04 = EOT <End of Transmission>
 Hex 0X06 = ACK <Acknowledge>

There are some additional steps taken before a control character is transmitted, but these steps are not included because they are not within the scope of this article. If you want more information about this process, please see RFC 1662. This RFC covers the framing style that PPP uses.

Received and Accepted Authentication Protocol xxyy (nnnn):

This message indicates that the configuration option for the authentication protocol to be used was accepted by both peers. The Windows 95 implementation of PPP can use one of three authentication methods: Password Authentication Protocol (PAP), Challenge-Handshake Authentication Protocol (CHAP), or the Shiva Password Authentication Protocol (SPAP).

PAP is the least secure of the three authentication types. It uses a clear-text transmission of the password from the client to the host. Such a transmission can be easily intercepted.

CHAP uses a secure challenge-response authentication method that allows the peer to be authenticated by an "authenticator" without transmitting the password in the clear as PAP does. The host sends a "challenge" to the client that consists of a randomly generated octet stream. Upon receiving the challenge, the peer concatenates the CHAP session ID, challenge value, and the user's password and then hashes it. This hash value and the user name of the peer being authenticated is then sent to the authenticator in a response. The authenticator maintains a database that correlates user names to passwords. When it receives the response from the peer, it looks up the user's password, performs the same concatenation and hashing, and compares the hash value it generates to the one from the peer. If the values match, the peer is authentic.

Hashing is a mathematical operation performed on a given value using a known algorithm to ensure that it is computationally unfeasible to reverse-engineer intelligible data from hashed data. The hashing algorithm most commonly used by CHAP is known as Message-Digest 5 (MD5). RFC 1321 outlines MD5.

SPAP is used exclusively with the Shiva LAN Rover remote access unit and when you are dialing into a Windows 95-based computer that is performing pass-through validation with a Novell NetWare server. It is more secure than PAP in that it provides encryption of PAP-transmitted passwords and access attempts to Novell NetWare binderies.

Received and Accepted Magic Number aabbxxyy:

A magic number is a hexadecimal value between two and four octets in length. It is a unique number generated from a random seed value that is determined from some external source, such as the intervals between the operator's keystrokes or the Nth decimal measurement of the system clock. Each peer generates a magic number during LCP negotiation. It is used to ensure that the PPP session actually involves two peers, in order to prevent looped-back connections. In Windows 95, if a peer receives a magic number equal to its own, or one of value 0, it is rejected, and the peers must re-exchange magic numbers. All diagnostic packets use the magic number to identify the sender of the packet.

Naking Possibly Loopback Magic Number:

When an invalid value for the magic number is received, that configuration option is returned to the offending peer in a Configure-Nak, prompting the exchange of a new and hopefully valid magic number. If the condition cannot be resolved, the link terminates immediately. This error is extremely rare. If it is received, try the following steps:

1. In the Dial-Up Networking connectoid, in TCP/IP Settings, set all options to "Server Assigned."

2. In the Network tool in Control Panel, configure the instance of TCP/IP bound to the Dial-Up Adapter with the user's TCP/IP information; specifically the DNS servers and IP addressing information.

3. Reboot and try the connection again.

Received and Accepted Protocol Field Compression Option:

This message indicates that both peers have agreed to compress the information contained in the PPP frame's protocol field. This reduces the size of that field from two octets to one. This configuration option was designed into PPP with slow or low-bandwidth links in mind.

Received and Accepted Address+Control Field Compression Option:

This message indicates that both peers have agreed to compress link-layer address and control fields within the PPP frame. This option is easily implemented as the values of these fields are constants in a Point-to- Point connection. Like the protocol field compression option, this option was included to improve performance on slow or low-bandwidth links.

Received Configure Reject for Callback Control Protocol Option:

This message is direction-specific. It indicates that the computer on which the Ppplog.txt file is currently being examined has rejected the use of the callback control protocol. This computer is usually a Dial-Up Networking server that does not support the callback control protocol. It is included in the Dial-Up Networking client for use with Microsoft Windows NT. With Windows 95, this rejection message is a non-catastrophic event. Other implementations of PPP, for security reasons, may use a callback feature to augment user authentication and require that the peer be called back.

Rejecting Callback Protocol Negotiation Request:

This message is direction-specific. It indicates that the computer on which the Ppplog.txt file is currently being examined has rejected an attempt by the peer to negotiate the use of the callback control protocol.

Received Unknown Code nn:

This message indicates that the computer on which the Ppplog.txt file is currently being examined has received an LCP packet that contains an LCP packet identifier that the implementation does not support. These packets are discarded.

Callback Control Protocol (CallbackCP)

The CallbackCP is seldom seen in the Ppplog.txt file. The messages shown in the Ppplog.txt file are described below, and a log example is provided later in this article.

CallbackCP : Layer Started:

This message is shown when the CallbackCP has not been rejected by either peer, and peer authentication was successful. One of the next three messages listed will follow this message.

Callback : Skipping Callback and Continuing with Current Connection:

This message indicates that the server supports the CallbackCP, and that the use of the peer callback has been disabled. This is commonly seen when dialing into a Windows NT RAS server.

Callback : Telling Server to Callback at User Specified Number:

When callback is enabled on the server, it can be configured to let the user supply the phone number to be called back with. When this is the case, the user will see a dialog box that prompts him or her to enter the phone number.

Callback : Telling Server to Callback at Administrator Specified Number:

When callback is enabled on the server, it can be configured with a preset number for each user. This is typically used in high-security environments to guard against the possibility that a user's logon information has been compromised. The user must be at a prearranged telephone number known to the server. When this is the case, the user will see a dialog box that prompts him or her to accept the "<Administrator>" password, at which point the callback procedure either terminates or continues depending on the user's selection of OK or Cancel.

CallbackCP : Layer Finished:

When the user has either supplied the necessary information or canceled the connection, this message is displayed. If the connection is going to be reestablished through a callback, PPP shuts down and enters a wait-for- call mode. When the server calls back, PPP answers the phone, final link negotiation takes place, and the connection is established.

CallbackCP : Layer Up:

When the peers skip the callback procedure, this message is shown. When the connection is terminated, the CallbackCP is closed just like any other protocol. The actual skipping of callback is not considered a catastrophic event, and as such, the protocol is not closed at that point.

Values for xxyy and nnnn

Values for xxyy in the [0xxx-3xxx] range represent the network-layer protocols of specific datagrams. Values in the [8xxx-bxxx] range identify NCP datagrams for the associated protocol, if it has one. Not all of the protocol identifiers listed below are present in the Windows 95 implementation of PPP. This information can be found in greater detail in RFC 1700. Listings with an asterisk (*) are supported in Windows 95.

 0021 Internet protocol *
 0023 OSI network layer
 002b Novell IPX *
 002d Van Jacobson compressed TCP/IP
 002f Van Jacobson uncompressed TCP/IP
 003d Multi-link
 003f NETBIOS framing *
 0049 Serial Data Transport protocol (PPP-SDTP)
 007d Reserved (Control Escape) [RFC 1661]
 007f Reserved (compression inefficient) [RFC 1662]
 00cf Reserved (PPP NLPID)
 00fb Compression on single link in multi-link group
 00fd First choice compression *

 8001-801f Not used - reserved [RFC 1661]
 8021 Internet Protocol Control protocol *
 8023 OSI Network Layer Control protocol
 802b Novell IPX Control protocol *
 803d Multi-Link Control protocol
 803f NETBIOS Framing Control protocol *
 807d Not used - reserved [RFC 1661]
 8049 Serial Data Control protocol (PPP-SDCP)
 80cf Not used - reserved [RFC 1661]
 80fb Compression on single link in multi-link group control
 80fd Compression Control protocol *
 80ff Not used - reserved [RFC 1661]
 c021 Link Control protocol *
 c023 Password Authentication protocol *
 c025 Link quality report
 c027 Shiva Password Authentication protocol *
 c029 CallBack Control protocol (CBCP) *
 c081 Container Control protocol [KEN]
 c223 Challenge Handshake Authentication protocol *
 c281 Proprietary Authentication protocol [KEN] *

Sample Ppplog.txt Files

This section contains examples of Ppplog.txt files generated during different types of PPP connections, both successful and unsuccessful. These examples have been interpreted and commented to show the value of each part of the Ppplog.txt file as applied during troubleshooting sessions.

Example 1 - Windows 95/Windows 95 [NetBEUI]

01) 35.15 - Remote access driver log opened. 02) 35.15 - Installable CP VxD SPAP is loaded. 03) 35.15 - Server type is PPP (Point-to-Point Protocol). 04) 35.15 - FSA : Adding Control Protocol 80fd (CCP) to control protocol

    chain.

    chain.

    8021 (IPCP).

    802b (IPXCP).

    protocol...

    protocol chain.

    chain.

    chain.

    chain.

    option.

    (CHAP).

    option.

Lines 1-12:

Lines 1-12 outline the computer's current configuration: which protocols are bound and enabled, what the server type is, and so on. In a PPP phase diagram, this section would most closely correspond to the Link-Dead phase. Lines 5-7 are important as they describe the status of the network protocols installed. At least one of the three protocols should say "Adding Control Protocol..." or the connection will fail. In this example, IP and IPX are disabled in the connectoid used to make the connection; only NetBEUI will be used.

However, if lines 5-7 looked like this:

 Protocol not bound - skipping control protocol 803f (NBFCP).
 Protocol disabled by user - skipping control protocol 8021 (IPCP).
 Protocol disabled by user - skipping control protocol 802b (IPXCP).

Lines 13-21:

Lines 13-21 show the Link Control Protocol (LCP) negotiating the operational parameters for link-layer control of the connection, illustrating the Link Establishment phase.

In this example, the process is completed the first time through. Depending on peer configuration, option negotiation can be repeated several times, until both sides agree on the options and their values. This process must finish. If it does not, the connection is terminated immediately.

When there is a hardware problem related to the modem or serial cable, or if the phone line is unreliable, it is common for this portion of the Ppplog.txt file to resemble the following:

 Callback negotiation enabled.
 Layer started.
 Layer finished.

1. The modem, cable, or serial port is bad.

2. Enable the Post-Dial Terminal window to verify that there are no menus to navigate or additional information required from the user after connection to start the PPP connection.

3. You may be using the wrong line protocol type (PPP instead of SLIP, and so on).

Lines 22-24 log the actions taken during the Authentication phase of the PPP connection. If peer authentication fails, the connection must terminate immediately. Lines 22-24 document this process. Normally, this portion of the Ppplog.txt will be only three lines long. However, depending on the type of authentication taking place, this section can be much longer. When PAP is used for peer authentication, the number of password retries can be infinite, unless there is a mechanism in place to limit the number of tries.

Lines 25-32:

If user authentication finishes, the next step is to configure the negotiated network protocols for use. This is the Network Layer Configuration phase, and it continues until the operational parameters for all protocols common to both peers have been negotiated. If this is successful, the following message will be displayed:

 FSA : Last control protocol is up.

 FSA : No network protocols were successfully negotiated.

Lines 33-51:

When either peer, whether by user or administrative (automaton) action, decides to end the PPP session, the connection transitions to the Link Termination phase. This is initiated when one peer transmits a Terminate- Request packet. When all upper-level protocols have been closed, the peer transmits a Terminate-Ack and the connection then closes completely.

For the most part, this section lists the session statistics, such as frames transmitted, CRC errors, and so on. This information can be useful when troubleshooting. For example, if you are being spontaneously disconnected, and you have an unusually high number of CRC errors (with a good modem, 1-2 are allowable), you might want to have your telephone lines checked for excessive noise. The telephone line is not the world's friendliest transmission medium, and while the quality of telephone connections is generally excellent, in some areas, and during certain weather conditions, the line quality can be very poor. When the modems cannot maintain a reliable connection, they disconnect. With external modems, a poorly made serial cable can also be a problem. A high-quality, well-shielded cable is desirable for the best performance with an external modem.

Example 2 - Windows 95/Internet Service Provider (ISP) [TCP/IP]

01) 26.07 - Remote access driver log opened. ... 02) 27.59 - IPCP : Layer started. 03) 27.59 - IPCP : IP address is 0. 04) 27.76 - IPCP : Received and accepted compression protocol request f 0. 05) 27.76 - IPCP : Received and accepted IP address of 95aed753. 06) 28.83 - IPCP : Changing IP address from 0 to c7aef648. 07) 28.83 - IPCP : Accepting primary DNS 95aed305. 08) 29.35 - IPCP : Layer up. 09) 29.35 - FSA : Last control protocol is up. 10) 10.39 - Remote access driver is shutting down. ... 11) 10.39 - LCP : Layer down. 12) 10.39 - IPCP : Layer down. 13) 10.92 - Remote access driver log closed.

Lines 2-8:

These lines document the procedure by which the client is assigned an IP address by the ISP. Initially, the client's IP address is 0, as shown by line 3. IP addresses are assigned to the client by the host. The host can also assign the client primary and secondary nameserver (DNS and WINS) addresses. To determine if your ISP will assign DNS addresses in the event that you do not specify them, you can do one of two things:

1. Call your IPS and ask.

2. Set your connectoid to "Server assigned name server addresses" and use Winipcfg.exe to see if the server has assigned DNS addresses.

 Binary:  11000111 10101110 11110110 01001000
 Hex:     C7-AE-F6-48
 Decimal: 199.174.246.72

With line 9, the connection has stabilized and interaction with the Internet is possible. Line 10 indicates that an administrative action (the user or the host) has caused the connection to begin closing. The remaining lines chronicle the status transitions of the LCP and IPCP modules. With line 13, the connection has been completely terminated, and all parameters negotiated during the connection have been flushed from the TCP/IP stack.

Example 3 - Windows 95/Windows NT 3.51 RAS [NetBEUI, IPX/SPX, TCP/IP]

01) 13.94 - Remote access driver log opened. ... 02) 13.95 - LCP : Callback negotiation enabled. 03) 13.95 - LCP : Layer started. 04) 17.31 - LCP : Received and accepted ACCM of 0. 05) 17.31 - LCP : Received and accepted authentication protocol c223

    (CHAP).

    option.

    connection.

Lines 3-9:

Lines 3-9 show the LCP configuration. An ACCM of 0 was negotiated, indicating that no characters are flagged for transparent transmission.

Lines 10-12:

This is the point at which the Windows 95 DUN client logs into the Windows NT RAS server. If the user has specified in the properties for the Client for Microsoft Networks that he or she wants to log into the Windows NT domain, that takes place after the user has logged into the RAS server. In this example, the client logged into a Windows NT domain. There is nothing in the Ppplog.txt file that indicates this difference.

Lines 13-15:

These lines illustrate something common to Windows NT RAS servers: the use of the Callback Control Protocol (CallbackCP or CBCP). Most of the time, the server has this option disabled, and as such, the sequence shown above takes place. This is normal.

Lines 16-35:

Lines 16, 17, and 19 show the NCPs for the installed protocols starting. All were selected in the connectoid, so PPP will attempt to configure and open them.

Line 18 is a status message from IPCP indicating the initial IP address of the client, 0. This is normal and is expected.

Lines 20, 21, and 28 show the Compression Control Protocol (CCP) as it starts, negotiates the compression options for the connection, and then transitions to the Up (operating) state.

Lines 22-24 show the IPX Control Protocol (IPXCP) receiving and setting its IPX network and node numbers, then opening. At this point, IPX/SPX is configured and functioning.

Lines 25-27 and 32-34 show the configuration of the TCP/IP protocol, handled by the Internet Protocol Configuration protocol (IPCP). The RAS server used for this example supports DHCP, which handles the assignment of WINS and node IP addresses. With line 34, TCP/IP is configured and functioning.

Lines 29-31 document the failure of the NetBIOS Frames Control protocol to be properly configured. Line 29 lists the actual cause for failure:

 NBFCP : NAK received - Projection failed.

Lines 36-45:

Line 36 indicates that the connection has been terminated, and from this point on, all the NCPs shut down, ending with the LCP entering the Finished state at line 44. PPP has come full-circle to the Link-Dead phase.

NOTE: Between lines 36 and 37, the link statistics are usually displayed. They have been removed for this example.

Example 4 - Windows 95/Windows NT [CallbackCP Example]

Nearly all messages have been removed from the example below. This example is provided to illustrate the flow of a Windows 95 DUN connection to a server that supports the CallbackCP option. In this particular connection, the user was allowed to specify the phone number.

01) 12.93 - Remote access driver log opened. ... 02) 12.93 - LCP : Callback negotiation enabled. 03) 12.93 - LCP : Layer started. ... 04) 13.17 - LCP : Layer up. 05) 13.17 - CHAP : Layer started. ... 06) 13.52 - CHAP : Layer up. 07) 13.52 - CallbackCP : Layer started. 08) 16.28 - Callback : Telling server to callback at user specified

    number.

    number.

 <server calls back at this point>

Lines 7-11:

These lines are the most critical part of the connection. If there are any errors here, the callback will fail. There are currently no examples of this failing due to an error in the implementation of PPP.

The most common cause for failure is a modem that is physically set using DIP switches or jumpers to the S0=0 condition (auto-answer disabled). In some cases, the switch setting will override any command issued to set the modem to answer after 'n' number of rings (ATS0=n). The next most common cause for failure is PCMCIA modems connected to a telephone network (either the PSTN or a PBX-type environment) that is not supplying enough ring voltage to trip the modem's ring-detect circuit. Unfortunately, in this case, there is nothing that can be done.

Either way, the best way to test this condition is to use a terminal program such as HyperTerminal to issue the ATS0=2 command to the modem, and dial the line the modem is connected to. If the modem does not answer the line, the modem has a hardware-related problem as described above. If it does, you may want to add the S0 command to the modem's initialization string.

Line 15:

This is the point where DUN enters the wait-for-call state. When the server calls back, the log is opened again.

The one thing to remember is that network-layer protocols do not go through option negotiation until the callback has finished. Just because the peers agree to the callback does not mean that the protocol configuration is correct. If the callback works, and protocol negotiation fails, continue to troubleshoot the issue normally.