A Sample PPP Connection

To actually see the PPP connection establishment process in Windows 2000, there are two tools available:

  1. Network Monitor, a packet capture and analysis tool, is used to capture all PPP packets sent over a serial link including connection establishment and PPP-encapsulated user data.

  2. PPP tracing is used to create a log of the PPP packets exchanged during the PPP connection establishment process.

Network Monitor

To capture PPP packets with Network Monitor, set the capture network to the network corresponding to the dial-up connection and begin capturing PPP frames as desired. You can use Network Monitor to:

  • Troubleshoot the PPP connection establishment process.

  • Ensure that PPP payloads are being encrypted.

  • Ensure that PPP payloads are being compressed.

note-icon

Note

If compression or encryption is being used, then the PPP payload is not interpreted by Network Monitor. Compressed or encrypted payloads are indicated with the PPP protocol ID of 3D (assuming protocol ID compression). To see the structure of user data within PPP payloads, disable compression and encryption.

When using Network Monitor, keep the following in mind:

  • Captured PPP frames do not contain a Flag character but do contain an Ethernet-like source address and destination address. This behavior is due to the fact that Network Monitor receives the packets from the Ndiswan.sys driver. Recall that Ndiswan.sys is an intermediate NDIS driver that looks like an Ethernet adapter to protocols.
    For each PPP frame, the Ethernet-like source and destination addresses are both set to either SEND or RECV to indicate that the PPP frame was either sent or received by the computer on which the capture was taken. The SEND and RECV addresses do not necessarily identify the traffic of a remote access server or remote access client. If the capture was taken on the remote access server, then SEND frames were sent by the remote access server and RECV frames were sent by the remote access client. If the capture was taken on the remote access client, then SEND frames were sent by the remote access client and RECV frames were sent by the remote access server.

  • Captured PPP frames contain an Address or Control field regardless of whether address and control field compression are negotiated.

  • Protocol ID compression is usually negotiated with Microsoft PPP peers, making the PPP Protocol ID a single byte when possible.

  • Use Network Monitor display to view only the traffic of desired protocols. For example, to view only the IPCP negotiation, set the display filters to disable the display of all protocols except IPCP.

The following printout is an example of a PPP connection establishment process captured with Network Monitor showing only the frame summaries. The entries are indented to improve readability.

1 8.726 SEND SEND LCP

Config Req Packet, Ident = 0x00, Length = 36

2 8.796 RECV RECV LCP

Config Req Packet, Ident = 0x00, Length = 25

3 8.796 SEND SEND LCP

Config Ack Packet, Ident = 0x00, Length = 25

4 8.816 RECV RECV LCP

Config Reject Packet, Ident = 0x00, Length = 17

5 8.816 SEND SEND LCP

Config Req Packet, Ident = 0x01, Length = 23

6 8.886 RECV RECV LCP

Config Ack Packet, Ident = 0x01, Length = 23

7 8.886 SEND SEND LCP

Ident Packet, Ident = 0x02, Length = 18

8 8.886 SEND SEND LCP

Ident Packet, Ident = 0x03, Length = 23

9 8.886 RECV RECV PPPCHAP

Challenge, ID = 0x 1: Challenge

10 8.886 SEND SEND PPPCHAP

Challenge, ID = 0x 1: Response, administrator

11 8.976 RECV RECV PPPCHAP

Challenge, ID = 0x 1: Success

12 8.976 RECV RECV CBCP

Callback Request, Ident = 0x01

13 8.976 SEND SEND CBCP

Callback Response, Ident = 0x01

14 8.996 RECV RECV CBCP

Callback Acknowledgement, Ident = 0x01

15 8.996 SEND SEND CCP

Configuration Request, Ident = 0x04

16 8.997 SEND SEND IPCP

Configuration Request, Ident = 0x05

17 8.997 RECV RECV CCP

Configuration Request, Ident = 0x01

18 9.017 RECV RECV IPCP

Configuration Request, Ident = 0x02

19 9.037 RECV RECV IPXCP

Configuration Request, Ident = 0x03

20 9.037 RECV RECV NBFCP

Configuration Request, Ident = 0x04

21 9.117 SEND SEND IPXCP

Configuration Request, Ident = 0x06

22 9.147 SEND SEND CCP

Configuration Acknowledgement, Ident = 0x01

23 9.147 SEND SEND IPCP

Configuration Acknowledgement, Ident = 0x02

24 9.167 SEND SEND IPXCP

Configuration Acknowledgement, Ident = 0x03

25 9.167 SEND SEND LCP

Protocol Reject Packet, Ident = 0x07, Length = 32

26 9.237 RECV RECV CCP

Configuration Reject, Ident = 0x04

27 9.237 RECV RECV IPCP

Configuration Reject, Ident = 0x05

28 9.237 SEND SEND IPCP

Configuration Request, Ident = 0x08

29 9.257 RECV RECV IPXCP

Configuration No Acknowledgement, Ident = 0x06

30 9.257 SEND SEND IPXCP

Configuration Request, Ident = 0x09

31 9.287 RECV RECV IPCP

Configuration No Acknowledgement, Ident = 0x08

32 9.287 SEND SEND IPCP

Configuration Request, Ident = 0x0A

33 9.287 RECV RECV IPXCP

Configuration Acknowledgement, Ident = 0x09

34 9.327 RECV RECV IPCP

Configuration Acknowledgement, Ident = 0x0A

35 10.729 SEND SEND CCP

Configuration Request, Ident = 0x04

36 10.960 RECV RECV CCP

Configuration Reject, Ident = 0x04

37 10.960 SEND SEND CCP

Configuration Request, Ident = 0x0B

38 10.960 RECV RECV CCP

Configuration Acknowledgement, Ident = 0x0B

The trace was captured on the remote access client. Therefore, the SEND frames were sent from the remote access client and the RECV frames were sent from the remote access server. In this trace, you can see the four phases of the PPP connection establishment:

  • Phase 1: PPP configuration is done in frames 1 through 8 by using the exchange of LCP configuration packets.

  • Phase 2: Authentication is done in frames 9 through 11 where the user's credentials are verified.

  • Phase 3: Callback is done in frames 12 through 14.

  • Phase 4: Protocol configuration is done in frames 15 through 38 where compression, encryption, IP, and IPX are configured.

In addition to the summary view, Network Monitor can also expand frames for detailed analysis. For example, frame 1 from this trace is displayed as:

FRAME: Base frame properties

FRAME: Time of capture = Nov 18, 1998 15:23:6.967

FRAME: Time delta from previous physical frame: 0 milliseconds

FRAME: Frame number: 1

FRAME: Total frame length: 50 bytes

FRAME: Capture frame length: 50 bytes

FRAME: Frame data: Number of data bytes remaining = 50 (0x0032)

PPP: Link Control Protocol Frame (0xC021)

PPP: Destination Address = SEND_

PPP: Source Address = SEND_

PPP: Protocol = Link Control Protocol

LCP: Config Req Packet, Ident = 0x00, Length = 36

LCP: Code = Configuration Request

LCP: Identifier = 0 (0x0)

LCP: Length = 36 (0x24)

LCP: Options: ASYNC.MAP:00 00 00 00-MAGIC#:0x0C05-PROT.COMP- ADR/CF.COMP-CALL.BACK:Unkn---

LCP: ASYNC.MAP:00 00 00 00

LCP: Option Type = Async Control Character Map

LCP: Option Length = 6 (0x6)

LCP: Async Control Character Map = 00 00 00 00

LCP: MAGIC#:0x0C05

LCP: Option Type = Majic Number

LCP: Option Length = 6 (0x6)

LCP: Magic Number = 3077 (0xC05)

LCP: PROT.COMP

LCP: Option Type = Protocol Field Compression

LCP: Option Length = 2 (0x2)

LCP: ADR/CF.COMP

LCP: Option Type = Address and Control Field Compression

LCP: Option Length = 2 (0x2)

LCP: CALL.BACK:Unkn

LCP: Option Type = Callback

LCP: Option Length = 3 (0x3)

LCP: CallBack = 0x06

LCP: Multilink Maximum Receive Reconstructed Unit

LCP: Option Type = 0x11

LCP: Option Length = 4 (0x4)

LCP: Multilink Endpoint Discriminator

LCP: Option Type = 0x13

LCP: Option Length = 9 (0x9)

Network Monitor captures can also be saved as files and sent to Microsoft support professionals for analysis.

PPP Tracing

Tracing is a facility of Windows 2000 remote access and routing components that allow you to optionally enable and disable the recording of programming code and network events to a file.

You enable PPP tracing by selecting Enable Point-to-Point Protocol (PPP) Logging from the Event Logging tab on the properties of a remote access server in the Routing and Remote Access snap-in.

The file Ppp.log is created in the % Systemroot %\tracing folder and contains information about the PPP connection establishment process. The PPP log generated by PPP tracing contain the programming calls and actual packet contents of PPP packets for PPP control protocols. PPP tracing cannot be used to view PPP user data sent across the connection.

The following printout is an excerpt from a PPP trace of a PPP connection establishment process. The entries are indented to improve readability.

[1472] 15:57:50:094: Line up event occurred on port 5

[1472] 15:57:50:104: Starting PPP on link with IfType=0x0,IPIf=0x0,

IPXIf=0x0

[1472] 15:57:50:104: RasGetBuffer returned ae70054 for SendBuf

[1472] 15:57:50:104: FsmInit called for protocol = c021, port = 5

[1472] 15:57:50:104: ConfigInfo = 273e

[1472] 15:57:50:104: APs available = 1

[1472] 15:57:50:104: FsmReset called for protocol = c021, port = 5

[1472] 15:57:50:104: Inserting port in bucket # 5

[1472] 15:57:50:104: Inserting bundle in bucket # 6

[1472] 15:57:50:104: FsmOpen event received for protocol c021 on port 5

[1472] 15:57:50:104: FsmThisLayerStarted called for protocol = c021,

port = 5

[1472] 15:57:50:104: FsmUp event received for protocol c021 on port 5

[1472] 15:57:50:104: <PPP packet sent at 11/04/1998 23:57:50:104

[1472] 15:57:50:104: <Protocol = LCP, Type = Configure-Req, Length =

0x2f, Id = 0x0, Port = 5

[1472] 15:57:50:104: <C0 21 01 00 00 2D 02 06 00 00 00 00 03 05 C2 23

|.!...-.........#|

[1472] 15:57:50:104: <80 05 06 72 5F 50 9A 07 02 08 02 0D 03 06 11 04

|...r_P..........|

[1472] 15:57:50:104: <06 4E 13 09 03 00 60 08 3E 46 07 17 04 00 03 00

|.N....`.>F......|

[1472] 15:57:50:104: InsertInTimerQ called portid=6,Id=0,Protocol=c021,

EventType=0,fAuth=0

[1472] 15:57:50:104: InsertInTimerQ called portid=6,Id=0,Protocol=0,

EventType=3,fAuth=0

[1472] 15:57:50:104: >PPP packet received at 11/04/1998 23:57:50:104

[1472] 15:57:50:104: >Protocol = LCP, Type = Configure-Req, Length =

0x26, Id = 0x0, Port = 5

[1472] 15:57:50:104: >C0 21 01 00 00 24 02 06 00 00 00 00 05 06 00 00

|.!...$..........|

[1472] 15:57:50:104: >C0 05 07 02 08 02 0D 03 06 11 04 06 4E 13 09 03

|._..........N...|

[1472] 15:57:50:104: >00 60 08 52 F9 D8 00 00 00 00 00 00 00 00 00 00

|.`.R............|

The last three lines of this trace excerpt is a hexadecimal display of the same LCP packet as frame 1 of the previous Network Monitor trace. To understand this frame, you must manually parse this frame according to the PPP and LCP packet structure. An example of the parsing of this PPP frame is listed in Table 7.15.

Table   7.15 Parsing of the LCP Configuration-Request

Bytes

Meaning

C0 21

PPP Protocol ID for LCP.

01

LCP Code for a Configure-Request.

00

LCP Identifier for this Configure-Request.

00 24

Length in bytes of the LCP packet (36 bytes long).

02

LCP option for Asynchronous Control Character Map (ACCM).

06

Length in bytes of the ACCM option.

00 00 00 00

Data for the ACCM option.

05

LCP option for the magic number.

06

Length in bytes of the magic number option.

00 00 C0 05

Data for the magic number option.

07

LCP option for protocol compression.

02

Length in bytes of the protocol compression option.

08

LCP option for address and control field compression.

02

Length in bytes of the address and control field compression option.

0D

LCP option for callback.

03

Length in bytes of the callback option.

06

Callback option data.

11

LCP option for the Multilink Maximum Receive Reconstructed Unit. Multilink LCP options are discussed in the "Multilink and Bandwidth Allocation Protocol" section of this chapter.

04

Length in bytes of the Multilink Maximum Receive Reconstructed Unit option.

06 4E

Multilink Maximum Receive Reconstructed Unit option data.

13

LCP option for the Multilink Endpoint Discriminator option.

09

Length in bytes of the Multilink Endpoint Discriminator option.

03 00 60 08 52 F9 D8

Multilink Endpoint Discriminator option data.

As you can see, Network Monitor is the easier tool for the interpretation of PPP traffic. However, the PPP trace contains valuable internal component interaction information that can be useful to troubleshoot connection problems and behavior. When in doubt, obtain both a Network Monitor capture and a PPP trace.

note-icon

Note

PPP tracing in Windows 2000 is the same as the PPP log feature found in Windows NT 4.0 and earlier.