Decoding Windows ppp/rasipcp traces - PPP

This is a discussion on Decoding Windows ppp/rasipcp traces - PPP ; 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 ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: Decoding Windows ppp/rasipcp traces

  1. Decoding Windows ppp/rasipcp traces


    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: 0x34, Id = 0x0, Port = 257
    [1532] 16:51:38:431: |.!...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


  2. Re: Decoding Windows ppp/rasipcp traces

    Well,
    Ethereal is absolutely amazing. I use it all the time on Windows boxes.
    J
    --
    Check my web site for tips on insuring safe computing in wired and wireless
    homenetworking environments!
    www.pccitizen.com

    "Chris Miller" wrote in message
    news:vti9pk44rlm82@corp.supernews.com...
    >
    > 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: > 0x34, Id = 0x0, Port = 257
    > [1532] 16:51:38:431: > |.!...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
    >




  3. Re: Decoding Windows ppp/rasipcp traces

    In article ,
    Chris Miller wrote:

    [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: >0x34, Id = 0x0, Port = 257
    >[1532] 16:51:38:431: >|.!...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.


    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: patrick@klos.com
    Klos Technologies, Inc. Web: http://www.klos.com/
    ==================== What goes around, comes around... =====================

  4. Re: Decoding Windows ppp/rasipcp traces

    Chris Miller writes:
    > 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


    Since nobody responded with an actual decode ...

    > 0x34, Id = 0x0, Port = 257
    > [1532] 16:51:38:431: > |.!...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
    > |................|


    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.

    --
    James Carlson, Solaris Networking
    Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677

  5. Re: Decoding Windows ppp/rasipcp traces

    Chris Miller wrote:
    > 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


    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: > 0x34, Id = 0x0, Port = 257
    > [1532] 16:51:38:431:
    [...]
    > 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.
    >

    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=O N
    [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.
    --
    Alan J. McFarlane
    http://homepage.ntlworld.com/alanjmcf/
    Please follow-up in the newsgroup for the benefit of all.




  6. Re: Decoding Windows ppp/rasipcp traces



    patrick@klos.com wrote:
    > In article ,
    > Chris Miller wrote:
    >
    > [I didn't want to turn this into an advertisement, but the lack of an
    > email address forces me to post to the newsgroup]


    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


  7. Re: Decoding Windows ppp/rasipcp traces



    James Carson wrote:
    > Since nobody responded with an actual decode ...


    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.


    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


  8. Re: Decoding Windows ppp/rasipcp traces



    Alan J. McFarlane wrote:
    > Chris Miller wrote:


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


    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.


    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


  9. Re: Decoding Windows ppp/rasipcp traces

    Chris Miller writes:
    > 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.


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


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

    --
    James Carlson, IP Systems Group
    Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677