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