How to Interpret the Ppplog.txt File

ID: Q156435

The information in this article applies to:

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

Because PPP is the predominant connection type used today, this article focuses primarily on interpreting the Ppplog.txt file when a PPP connection is used. Information not related to troubleshooting, but instrumental in understanding the framework of PPP, is also provided.

Notes


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.


The next time you use the Dial-Up Adapter, the Ppplog.txt file is created in the Windows folder.

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

This structure can be broken into the following two logical parts:

HDLC Framing of PPP Data: 

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

The PPP frame's beginning and end is marked by a Flag sequence. In a data stream, the end of one frame and the beginning of the next is not noted by the presence of consecutive Flags; only one is needed. The field's length is one octet, and its value is always 01111110 (0x7e).

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 Protocol field can be either one or two octets in length, depending on whether protocol field compression is being used. It indicates the protocol contained within the PPP frame. With PPP, protocol identification numbers are based on the ISO 3309 extension mechanism for address fields. This states that if address field identifiers comply with the format stated in ISO 3309, implementations of PPP can reliably compress a 16-bit (2-octet) field down to an 8-bit (single octet) field while retaining all necessary information.

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.


Knowing the three classes of packets is important because a malfunctioning implementation of PPP can be indicated by the presence of a certain class of packet appearing at an inappropriate time. You may also see this behavior if the connection between the two peers is poor or the modems are misconfigured or malfunctioning. More information about the specific packets within each class and their relevance to the Ppplog.txt file is contained in the "Parsing the Ppplog.txt File" section of this article.

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)

It is important to note that because the majority of Windows 95 PPP connections are asynchronous, according to RFC 1662 the following configuration options will always be negotiated:

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

These options may not necessarily be negotiated in the order shown.

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

Depending on the protocol used for authentication, the client may be given an infinite number of logon attempts, although usually the limit is three. These protocols are described later in this article.

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

The following example uses the same conventions as the previous example for LPC option negotiation.

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: Layer Started:

This message, when prefixed with:
aaa: Layer Up:

This message, when prefixed with:
aaa: Layer Down:

This message, when prefixed with:
aaa: Layer Finished:

This message, when prefixed with:

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:
Remote Access Driver Log Opened:

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

The entries listed in this key are string values consisting of a description of the protocol for the value name, and the actual VxD file name for the value data.

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:
Note that SLIP, CSLIP, and Dial-Up Networking Server are not part of a default Windows 95 installation, but are installed separately. SLIP and CSLIP are installed with the Dial-Up Scripting tool included on the Windows 95 CD-ROM, or as part of the Internet Jumpstart Kit included with Microsoft Plus! for Windows 95. Dial-Up Networking Server is included only with Microsoft Plus!.

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.


If you have Windows 95 on floppy disks and you are interested in obtaining the Dial-Up Scripting tool, please see the following article in the Microsoft Knowledge Base:

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:
Adding Control Protocol xxyy (nnnn) to Control Protocol Chain:

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:



Received and Accepted ACCM of yyyyy:

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>

Using this method, all of the lower 128 ASCII characters (with the exception of DEL) can be mapped in the ACCM.

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.


If this, coupled with standard troubleshooting procedures, fails to resolve the issue, have the user contact his or her Internet service provider or system administrator.

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.
05) 35.15 - FSA : Adding Control Protocol 803f (NBFCP) to control protocol chain.
06) 35.15 - FSA : Protocol disabled by user - skipping control protocol 8021 (IPCP).
07) 35.15 - FSA : Protocol disabled by user - skipping control protocol 802b (IPXCP).
08) 35.15 - FSA : Adding Control Protocol c029 (CallbackCP) to control protocol...
09) 35.15 - FSA : Adding Control Protocol c027 (no desc.) to control protocol chain.
10) 35.15 - FSA : Adding Control Protocol c023 (PAP) to control protocol chain.
11) 35.15 - FSA : Adding Control Protocol c223 (CHAP) to control protocol chain.
12) 35.15 - FSA : Adding Control Protocol c021 (LCP) to control protocol chain.
13) 35.15 - LCP : Callback negotiation enabled.
14) 35.15 - LCP : Layer started.
15) 35.36 - LCP : Received configure reject for callback control protocol option.
16) 37.96 - LCP : Received and accepted ACCM of a0000.
17) 37.96 - LCP : Received and accepted authentication protocol c223 <CHAP).
18) 37.96 - LCP : Received and accepted magic number 995dc00.
19) 37.96 - LCP : Received and accepted protocol field compression option.
20) 37.96 - LCP : Received and accepted address+control field compression option.
21) 37.96 - LCP : Layer up.
22) 37.96 - CHAP : Layer started.
23) 38.37 - CHAP : Login was successful.
24) 38.37 - CHAP : Layer up.
25) 38.37 - NBFCP : Layer started.
26) 38.37 - CCP : Layer started.
27) 38.38 - FSA : Sending protocol reject for control protocol 8021.
28) 41.39 - CCP : Received and accepted compression value 1.
29) 41.40 - NBFCP : Layer up.
30) 44.37 - CCP : Received and accepted compression value 1.
31) 44.37 - CCP : Layer up.
32) 44.37 - FSA : Last control protocol is up.
33) 04.90 - Remote access driver is shutting down.
34) 04.90 - CRC Errors 0.
35) 04.90 - Timeout Errors 0.
36) 04.90 - Alignment Errors 0.
37) 04.90 - Overrun Errors 0.
38) 04.90 - Framing Errors 0.
39) 04.90 - Buffer Overrun Errors 0.
40) 04.90 - Incomplete Packets 0.
41) 04.90 - Bytes Received 62373.
42) 04.90 - Bytes Transmitted 9403.
43) 04.90 - Frames Received 323.
44) 04.90 - Frames Transmitted 330.
45) 04.90 - LCP : Layer down.
46) 04.90 - CHAP : Layer down.
47) 04.90 - NBFCP : Layer down.
48) 04.90 - CCP : Layer down.
49) 05.03 - LCP : Received terminate acknowledgment.
50) 05.03 - LCP : Layer finished.
51) 05.03 - Remote access driver log closed.

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).

The connection would fail with a "Dial-Up Networking could not negotiate..." error message. If this is the problem, determine which protocol is common to both computers, then make sure that it is loaded and bound to the Dial-Up Adapter on both computers.

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.

This is significant because the Ppplog.txt file does not list what Pppmac.vxd cannot make sense of. If one peer sends a frame that contains a valid Configure-Request packet, and it is damaged in transit, the receiving peer cannot identify it and it will be discarded as outlined in RFC 1661. If, within a certain amount of time, LCP configuration does not finish, the Finite State Automaton (FSA) will time out. As a consequence, the connection will be terminated. Typically, between 5-10 seconds elapse during a high-speed connection after carrier negotiation finishes before the connection is terminated due to LCP option negotiation failure. If you see this message sequence in a Ppplog.txt file, consider the following items:
  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:

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.

If network layer configuration is unsuccessful, the following message will be displayed:

FSA : No network protocols were successfully negotiated.

This will be accompanied by the "Dial-Up Networking could not negotiate..." error message in the user interface, and the connection will be terminated.

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.


In line 6, the client changes its IP address from 0 to C7-AE-F6-48. If the IP addresses look strange, it is because in the Ppplog.txt file, IP addresses are shown in hexadecimal format. The decimal equivalents of IP addresses are used when configuring network connections that use TCP/IP because they are easy to handle. The actual information is transmitted in binary, which would be difficult to remember because the addresses total 32 binary digits. For example:

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

Lines 9-13:

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).
06) 17.31 - LCP : Received and accepted magic number 5b88.
07) 17.31 - LCP : Received and accepted protocol field compression option.
08) 17.31 - LCP : Received and accepted address+control field compression option.
09) 17.36 - LCP : Layer up.
10) 17.36 - CHAP : Layer started.
11) 19.25 - CHAP : Login was successful.
12) 19.25 - CHAP : Layer up.
13) 19.25 - CallbackCP : Layer started.
14) 19.26 - Callback : Skipping callback and continuing with current connection.
15) 19.46 - CallbackCP : Layer up.
16) 19.46 - IPXCP : Layer started.
17) 19.46 - IPCP : Layer started.
18) 19.46 - IPCP : IP address is 0.
19) 19.46 - NBFCP : Layer started.
20) 19.46 - CCP : Layer started.
21) 19.50 - CCP : Received and accepted compression value 1.
22) 19.57 - IPXCP : Changed net number from 0 to ed420f01.
23) 19.57 - IPXCP : Received and accepted peer node number 0 0 0 0 0 1.
24) 20.10 - IPXCP : Layer up.
25) 20.18 - IPCP : Changing IP address from 0 to 9d3a29bb.
26) 20.18 - IPCP : Accepting primary WINS 9d361099.
27) 20.18 - IPCP : Accepting backup WINS 9d36109b.
28) 23.15 - CCP : Layer up.
29) 23.33 - NBFCP : NAK received - Projection failed.
30) 23.33 - NBFCP : Layer down.
31) 23.48 - NBFCP : Layer finished.
32) 23.80 - IPCP : Received and accepted compression protocol request f 1.
33) 23.80 - IPCP : Received and accepted IP address of 9d3a2b98.
34) 23.80 - IPCP : Layer up.
35) 23.80 - FSA : Last control protocol is up.
36) 34.88 - Remote access driver is shutting down.
...
37) 34.88 - LCP : Layer down.
38) 34.88 - CHAP : Layer down.
39) 34.88 - CallbackCP : Layer down.
40) 34.88 - IPXCP : Layer down.
41) 34.88 - IPCP : Layer down.
42) 34.88 - CCP : Layer down.
43) 35.07 - LCP : Received terminate acknowledgment.
44) 35.07 - LCP : Layer finished.
45) 35.07 - Remote access driver log closed.

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.

This means that the client broadcast a packet to the remote network in an attempt to see if its network name was unique, and a computer responded as having the same name. Because NetBIOS is completely dependent on its NetBIOS name, a duplicate name on the same network cannot be tolerated. Therefore, the protocol closes immediately. Line 35 indicates that all NCP activity has completed and the link is ready to pass network-layer traffic.

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.
09) 17.11 - Callback : Telling server to callback at user specified number.
10) 17.25 - CallbackCP : Layer finished.
11) 17.25 - FSA : Preparing for callback from server.
12) 17.25 - LCP : Layer down.
...
13) 17.36 - LCP : Layer finished.
14) 17.37 - Remote access driver is shutting down.
...
15) 17.37 - Remote access driver log closed.

 <server calls back at this point>

16) 51.41 - Remote access driver log opened.
17) 51.42 - LCP : Layer started.
...
18) 53.40 - LCP : Layer up.
19) 53.40 - CHAP : Layer started.
...
20) 53.79 - CHAP : Layer up.
21) 53.79 - NBFCP : Layer started.
...
22) 58.41 - NBFCP : Layer up.
23) 58.41 - FSA : Last control protocol is up.
24) 40.66 - Remote access driver is shutting down.
...
25) 40.66 - LCP : Layer down.
...
26) 40.77 - LCP : Layer finished.
27) 40.77 - Remote access driver log closed.

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.

Additional query words: msn 


Keywords          : kbnetwork win95 wincomm win98 
Version           : 95
Platform          : WINDOWS 
Issue type        : kbhowto

Last Reviewed: January 29, 1999