Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-users: Re: [Wireshark-users] decoding packet data payload?

From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Sun, 04 May 2008 12:04:13 -0700
Malcolm Herbert wrote:
I have a captured PPP session inside a TCP stream created by userppp
with a TCP connection being used as the PPP transport instead of the
serial port[1].

I have the entire TCP packet capture and can see the complete HDLC-like
PPP frames inside the TCP data payload - I'd like wireshark to interpret this for me as I'm interested in seeing PPP at work.

Ultimately I'd like to get at the TCP data running inside that as well,
but this is less important at the moment.

This sounds like it should be a simple thing to achieve ... except that
I haven't yet found any references to doing this in the FAQ or from
elsewhere on the web.  How would I go about it?

I had thought wireshark would support this behaviour by default as there are many cases where protocols encapsulate others - IPIP or IPSec over TCP come to mind here ...

No. Given that TCP has no notion of packet boundaries (the service it provides is a byte stream), and protocols you'd tunnel inside TCP *do* have such a notion, for each such protocol there would need to be some mechanism to allow byte boundaries to be determined.

Some protocols already have packet lengths in the packet header, but even those would need the dissector to do special work when run atop TCP - we couldn't just define every single dissector for those protocols to be usable atop TCP without adding "encapsulation over TCP" support to them.

Other protocols have other mechanisms to indicate packet boundaries, and would need even more work.

The PPP dissector was written under the assumption that the packets come from the OS's packet capture mechanism, and therefore that the HDLC flags are not part of the packet and any escaping of byte sequences identical to the flag has been removed. That is a correct assumption for most PPP captures, so the dissector is working correctly in that case. However, when PPP is being tunneled inside a lower-level protocol that Wireshark dissects, and an HDLC-encapsulated byte stream is transported by that lower-level protocol, this would require that additional code be written to find packet boundaries, construct the un-escaped PPP packets, and hand those to the PPP dissector. I don't think that code has been written (although this issue did, as I remember, come up with some mobile phone protocol atop which PPP is transported).

Alternately, since I'm wanting to look at PPP, would it be better to
capture the PPP session directly from a serial link somehow?

You would have the same problem in that case.

If, however, you did the un-framing and un-escaping in a program, and had Wireshark capture from that program over a pipe, that might be easier, and wouldn't require Wireshark to be changed (at least not on UN*X).