Remote Access Server

A Sample PPP Connection

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

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

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

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