Decoding Windows ppp/rasipcp traces

  • Thread starter Thread starter Chris Miller
  • Start date Start date
C

Chris Miller

I'm trying to debug a connection issue from a w2k client machine. I can
decode the server side trace data (Livingston PPP decoder), but I need
to decode the client side where the problem appears to be occurring. I
haven't found anything in the way of tools mentioned on Usenet or
Microsoft's site. Does anyone know of a tool or procedure for decoding
these traces? Here's an example from the ppp.log under c:\winnt\tracing :

[1532] 16:51:38:431: <Protocol = LCP, Type = Configure-Req, Length =
0x34, Id = 0x0, Port = 257
[1532] 16:51:38:431: <C0 21 01 00 00 32 02 06 00 00 00 00 05 06 69 AF
|.!...2........i.|
[1532] 16:51:38:431: <38 DB 07 02 08 02 0D 03 06 11 04 06 4E 13 17 01
|8...........N...|
[1532] 16:51:38:431: <77 97 5A F6 F3 71 4E 2A 9B E3 80 47 1A 83 CC 3D
|w.Z..qN*...G...=|
[1532] 16:51:38:431: <00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|................|

On the server side, I can turn this :

Received LCP_CONFIGURE_REQUEST on port S0 of 46 bytes containing:wire
bytes 50
01 01 00 32 02 06 00 00 00 00 05 06 57 99 31 35
07 02 08 02 0d 03 06 11 04 06 4e 13 17 01 fc 3d
3f 15 6d 27 41 f1 b4 f1 87 79 e2 e9 e1 70 00 00
00 00

to this using Livingston's PPP decoder :

Received LCP_CONFIGURE_REQUEST on port S0 of 46 bytes containing:wire
bytes 50
01 01 00 32 02 06 00 00 00 00 05 06 57 99 31 35 07 02 08
02 0D 03 06 11 04 06 4E 13 17 01 FC 3D 3F 15 6D 27 41
F1 B4 F1 87 79 E2 E9 E1 70 00 00 00 00
Packet Info: Code: 01, ID: 01, 50 bytes.
Async-Control-Character-Map [0x02], length: (6 bytes), [0x00000000]
Magic-Number [0x05], length: (6 bytes), [0x57993135]
Protocol-Field-Compression [0x07], length: (2 bytes)
Address-and-Control-Field-Compression [0x08], length: (2 bytes)
Callback [0x0D], length: (3 bytes), [0x06]
Multilink-MRRU [0x11], length: (4 bytes), [0x064E]
Max-Receive-Reconstructed-Unit (MRRU): 1614 bytes.
Multilink-Endpoint-Discriminator [0x13], length: (23 bytes),
[0x01FC3D3F156D2741F1B4F18779E2E9E17000000000]
Class [0x01]: Locally Assigned Address FC 3D 3F 15 6D 27 41 F1 B4 F1
87 79 E2 E9 E1 70 00 00 00 00

Unfortunately this tool doesn't help with the Microsoft traces as you
would expect. Any help is much appreciated.

Chris
 
[I didn't want to turn this into an advertisement, but the lack of an
email address forces me to post to the newsgroup]
I'm trying to debug a connection issue from a w2k client machine. I can
decode the server side trace data (Livingston PPP decoder), but I need
to decode the client side where the problem appears to be occurring. I
haven't found anything in the way of tools mentioned on Usenet or
Microsoft's site. Does anyone know of a tool or procedure for decoding
these traces? Here's an example from the ppp.log under c:\winnt\tracing :

[1532] 16:51:38:431: <Protocol = LCP, Type = Configure-Req, Length =
0x34, Id = 0x0, Port = 257
[1532] 16:51:38:431: <C0 21 01 00 00 32 02 06 00 00 00 00 05 06 69 AF
|.!...2........i.|
[1532] 16:51:38:431: <38 DB 07 02 08 02 0D 03 06 11 04 06 4E 13 17 01
|8...........N...|
[1532] 16:51:38:431: <77 97 5A F6 F3 71 4E 2A 9B E3 80 47 1A 83 CC 3D
|w.Z..qN*...G...=|
[1532] 16:51:38:431: <00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|................|

On the server side, I can turn this :

Received LCP_CONFIGURE_REQUEST on port S0 of 46 bytes containing:wire
bytes 50
01 01 00 32 02 06 00 00 00 00 05 06 57 99 31 35
07 02 08 02 0d 03 06 11 04 06 4e 13 17 01 fc 3d
3f 15 6d 27 41 f1 b4 f1 87 79 e2 e9 e1 70 00 00
00 00

to this using Livingston's PPP decoder :

Received LCP_CONFIGURE_REQUEST on port S0 of 46 bytes containing:wire
bytes 50
01 01 00 32 02 06 00 00 00 00 05 06 57 99 31 35 07 02 08
02 0D 03 06 11 04 06 4E 13 17 01 FC 3D 3F 15 6D 27 41
F1 B4 F1 87 79 E2 E9 E1 70 00 00 00 00
Packet Info: Code: 01, ID: 01, 50 bytes.
Async-Control-Character-Map [0x02], length: (6 bytes), [0x00000000]
Magic-Number [0x05], length: (6 bytes), [0x57993135]
Protocol-Field-Compression [0x07], length: (2 bytes)
Address-and-Control-Field-Compression [0x08], length: (2 bytes)
Callback [0x0D], length: (3 bytes), [0x06]
Multilink-MRRU [0x11], length: (4 bytes), [0x064E]
Max-Receive-Reconstructed-Unit (MRRU): 1614 bytes.
Multilink-Endpoint-Discriminator [0x13], length: (23 bytes),
[0x01FC3D3F156D2741F1B4F18779E2E9E17000000000]
Class [0x01]: Locally Assigned Address FC 3D 3F 15 6D 27 41 F1 B4 F1
87 79 E2 E9 E1 70 00 00 00 00

Unfortunately this tool doesn't help with the Microsoft traces as you
would expect. Any help is much appreciated.
Click to expand...

You could try our product, PacketView Pro. It's not quite polished, but
it will capture the actual PPP packets right at the serial port. If you'd
like to try the DEMO version, you can download it from here:

ftp://ftp.klos.com/pub/demo/PacketViewProInstall.exe

Once you've installed the above, you will want to edit the PVPRO.DAT file
in your install directory (typically "C:\Program Files\PacketView Pro\").
Near the beginning of the file you'll see the "[COMPORTS]" section. Add
a line with the name of the serial port that the PPP connection is made
on. For example, if your PPP connection is using COM5, the top of the
file would look like this:

[COMPORTS]
COM5

Then when you start PacketView Pro, it will include an interface which will
include the PPP packets from that COM port.

The demo version limits you to capture only 32 packets at a time (use the
F4 function key to restart the capture).

Enjoy! If it doesn't decode the packets, you can save the trace file of
the packets in question and send them to me so I can see why it's not
decoding.

Note: PacketView Pro doesn't (yet) decode compressed or encrypted packets,
nor does it currently expand VJ compressed headers. All in good time (I
hope).

Patrick Klos
========= For LAN/WAN Protocol Analysis, check out PacketView Pro! =========
Patrick Klos Email: (e-mail address removed)
Klos Technologies, Inc. Web: http://www.klos.com/
==================== What goes around, comes around... =====================
 
Chris Miller said:
I'm trying to debug a connection issue from a w2k client machine. I
can decode the server side trace data (Livingston PPP decoder), but I
Click to expand...

Since nobody responded with an actual decode ...
0x34, Id = 0x0, Port = 257
[1532] 16:51:38:431: <C0 21 01 00 00 32 02 06 00 00 00 00 05 06 69 AF
|.!...2........i.|
[1532] 16:51:38:431: <38 DB 07 02 08 02 0D 03 06 11 04 06 4E 13 17 01
|8...........N...|
[1532] 16:51:38:431: <77 97 5A F6 F3 71 4E 2A 9B E3 80 47 1A 83 CC 3D
|w.Z..qN*...G...=|
[1532] 16:51:38:431: <00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|................|
Click to expand...

The first two octets (C0 21) are the protocol number, as described in
section 2 of RFC 1661. C021 is LCP. The next four are Code (01 -
Configure Request), Identifier (00), and Length (0032), as described
in section 5.

Following that are the options in type-length-value format, as
described in section 6 of the same RFC. These are:

02 06 00 00 00 00
- 2 - ACCM 00000000, RFC 1662

05 06 69 AF 38 DB
- 5 - Magic-Number option

07 02
- 7 - Protocol-Field-Compression

08 02
- 8 - Address-and-Control-Field-Compression

0D 03 06
- 13 - Callback, 6 - Microsoft-proprietary

11 04 06 4E
- 17 - Multilink MRRU - 1614; RFC 1990

13 17 77 97 5A F6 F3 71 4E 2A 9B E3 80 47 1A 83 CC 3D 00 00 00
00 00
- 19 - Endpoint-Discriminator; appears to be corrupt.
(Class 77 is nonsense.)

The IANA (www.iana.org) has lists of protocol numbers that might be
helpful.
 
Chris Miller said:
I'm trying to debug a connection issue from a w2k client machine. I
can decode the server side trace data (Livingston PPP decoder), but I
need to decode the client side where the problem appears to be
Click to expand...

Doesn't the Livingston device display both sent and received frames? The
PPP frames aren't meant to be changed on the link (normally(?)) so decoding
at one end may well be enough. If the frame content isn't being changed by
the link there's likely no need to look at the decode at both ends.

If the frame is changed by the link...well that might well be the problem...
occurring. I haven't found anything in the way of tools mentioned on
Usenet or Microsoft's site. Does anyone know of a tool or procedure
for decoding these traces? Here's an example from the ppp.log under
c:\winnt\tracing :

[1532] 16:51:38:431: <Protocol = LCP, Type = Configure-Req, Length =
0x34, Id = 0x0, Port = 257
[1532] 16:51:38:431: <C0 21 01 00 00 32 02 06 00 00 00 00 05 06 69 AF [...]
On the server side, I can turn this :

Received LCP_CONFIGURE_REQUEST on port S0 of 46 bytes containing:wire
bytes 50
01 01 00 32 02 06 00 00 00 00 05 06 57 99 31 35 [...]
Unfortunately this tool doesn't help with the Microsoft traces as you
would expect. Any help is much appreciated.
Click to expand...
I don't expect that; they are still PPP format frames regardless of which
end creates them.

It looks to me that if you remove the first two bytes of the Microsoft
dumped frames, the Livingston decoder will work on them. The Livingston's
dump doesn't include the Protocol Number (C021 for LCP) in its dumps for
some reason, Microsoft's does. Try that and see if it works.


When LCP goes up the PPP.LOG file does dump the parameters agreed , e.g.:
[888] 18:13:24:323: LCP Local Options-------------
[888] 18:13:24:323: MRU=1500,ACCM=-1,Auth=0,MagicNumber=0,PFC=ON,ACFC=ON
[888] 18:13:24:323: Recv Framing =
PPP,SSHF=OFF,MRRU=1500,LinkDiscrim=0,BAP=OFF
[888] 18:13:24:323: LCP Remote Options-------------
[888] 18:13:24:323: MRU=1500,ACCM=0,Auth=0,MagicNumber=0,PFC=ON,ACFC=ON
[888] 18:13:24:323: Send Framing = PPP,SSHF=OFF,MRRU=1500,LinkDiscrim=0

I don't know if there's a way to get decoding of the individual frames
though.
 
[I didn't want to turn this into an advertisement, but the lack of an
email address forces me to post to the newsgroup]
Click to expand...

Patrick,
thanks for your reply, I've grown accustomed to using an invalid email
address due to spam... Thanks for the pointed to your company's
software, I had taken a look at the web site earlier based on a post you
made to this group in the past. Unfortunately I needed to decode packets
from a trace a customer provided me and it wouldn't have been practical
to have him install the software on his system in this case. I did play
a bit with the software and it does seem to be very useful and have it's
place should further debugging have been required. See additional
replies for more on this story. Thanks again!

Chris
 
James said:
Since nobody responded with an actual decode ...
Click to expand...

Thanks for the pointer, this helped me track down the point in which the
failure occurs.
The IANA (www.iana.org) has lists of protocol numbers that might be
helpful.
Click to expand...

I found this at :

http://www.iana.org/assignments/ppp-numbers

Just to fill in the blanks, this problem occurred on a system that had
third party acceleration software installed. When performing tracing we
found that Windows was unable to perform IPCP tracing with the software
installed. Just as PAP negotiation was completing and IPCP would
normally start, Windows erroneously refused to negotiate IPCP and
appeared to become agitated that it received an IPCP configure request.
At this point Windows sent an LCP termination request. With the
acceleration software removed, connections were made normally. I've
personally used the software with w2k without incident.

I was able to gather enough information to open a case with the software
manufacturer, but where that will go remains to be seen. Somehow I see a
reinstall of Windows 2000 in our customer's future... It's too bad the
networking components aren't decoupled from the core OS, they could
probably be reinstalled to fix the problem as we've seen in similar
situations with Windows 9x...

Chris
 
Alan said:
Chris Miller <[email protected]> wrote:
Click to expand...
Doesn't the Livingston device display both sent and received frames? The
Sure.

PPP frames aren't meant to be changed on the link (normally(?)) so decoding
at one end may well be enough. If the frame content isn't being changed by
the link there's likely no need to look at the decode at both ends.
Click to expand...

Well all we could see on the server side was that we received an LCP
term req after sending a PAP ack and an IPCP config req. We wanted to
see if we could determine why Windows was shutting down the session
prematurely even though the right thing was happening on the server
side. (see other post).
It looks to me that if you remove the first two bytes of the Microsoft
dumped frames, the Livingston decoder will work on them. The Livingston's
dump doesn't include the Protocol Number (C021 for LCP) in its dumps for
some reason, Microsoft's does. Try that and see if it works.
Click to expand...

I did, but it didn't work. I had that that the decoder was written in C,
but it turns out it's just a Perl script and could easily be modified to
read Windows traces if necessary. The problem here seems to be caused by
the third party software although one might argue that Windows is doing
the wrong thing by refusing IPCP for no apparent reason then terminating
the connection. If anyone ever wants the Livingston PPP Decoder, you can
probably get a copy from the folks at portmasters.com although it isn't
on their website in the downloads area, they do have the program running
here :

http://portmasters.com/tech/support/dring.html

Chris
 
Chris Miller said:
Just to fill in the blanks, this problem occurred on a system that had
third party acceleration software installed. When performing tracing
we found that Windows was unable to perform IPCP tracing with the
software installed. Just as PAP negotiation was completing and IPCP
would normally start, Windows erroneously refused to negotiate IPCP
and appeared to become agitated that it received an IPCP configure
request.
Click to expand...

I've seen this reported before. There's some obscure menu in Windows
that "binds" a protocol to an interface, and if you leave the checkbox
for TCP/IP empty, DUN will reject IPCP.

Since I don't use any MS software, though, I can't say I have direct
experience with it. That might be enough information to search
elsewhere, though.
I was able to gather enough information to open a case with the
software manufacturer, but where that will go remains to be
seen. Somehow I see a reinstall of Windows 2000 in our customer's
future... It's too bad the networking components aren't decoupled from
the core OS, they could probably be reinstalled to fix the problem as
we've seen in similar situations with Windows 9x...
Click to expand...

Reinstalling should just never be necessary ... :-/
 
Back
Top