Re: PPP compression

[James Carlson <carlsonj@workingcode.com>]

On 12/21/14 13:37, Michael Richardson wrote:
> James Carlson <carlsonj@workingcode.com> wrote:
>     >> I tried to use pppdump with -p and -d. The input file I used was the
>     >> pcap file (packets.pcap) generated by tcpdump.
> 
>     > As I said, pppdump and pcap formats are not at all the same.  You'll
>     > have to convert to go this route.
> 
>     > Attached is a quick-and-dirty program I wrote to convert from the Linux
>     > libpcap variant and PPTP encapsulation you seem to be using and simple
>     > pppdump format.  I didn't bother with timestamps or other bits.  Maybe
>     > it'll work for you.
> 
> Do you think it would be worth having a tcpdump DLT type for pppdump stuff,
> and just wrap it all up into a pcap container?

It's an interesting idea, and I could see how there might be cases where
it may even be helpful, but I think it's the wrong thing to do.

These are fundamentally different things.  The pppdump stuff, at its
heart, is really an asynchronous serial recording mechanism.  It doesn't
know anything about packets or frames or other such L2 nonsense.  It
just records bytes going in and out in a format that can preserve
interesting information such as timing.

The original purpose of it was to record low-level async data to reveal
communications problems that caused AHDLC to go off the rails.  You
would not (ordinarily) want to use it to debug some sort of PPP, IP, or
higher-level problem.  Instead, you'd use the existing raw packet
mechanisms to record the packets.

In fact, when you're using pppd's "record" option (which saves data in
the pppdump format), it actually forks up a separate relay process and
runs PPP over a pty pair instead of the user's specified serial port.
That relay process is what saves the data while copying data back and
forth between the serial port and the pty.  It's a brutal trip back and
forth in and out of the kernel multiple times on each packet, and the
original data are (unfortunately) sometimes mangled in the process due
to pty and serial port issues.

It would probably be nice to have some sort of raw recording mechanism
for AHDLC's in-kernel decoder (and perhaps HDLC frames as well, for PPP
over synchronous lines) so that packet capture tools can get better
low-level data, but I don't think this is the right long-term mechanism.

I suggested pppdump as a way out for this particular case because this
one user wants to decode compressed data, and this is one thing that
pppdump happens to know how to do (albeit in a very limited way).

tcpdump datalink type values are, I think, a higher-level concept.

A better path forward for the original poster's problem would be to
extend the existing wireshark decoders for PPP, which already know about
LCP negotiation and the existence of compressed data, so that they know
how to decode at least the freely-available compressed data formats.  It
looks like a nice little project for someone.  I suppose if I find a
whole bunch of time at some point, I might do it, but don't let that
stop anyone else from trying!

-- 
James Carlson         42.703N 71.076W         <carlsonj@workingcode.com>