Re: PPP compression

[arthurpaulino <arthurpaulino@great.ufc.br>]

[-- Attachment #1: Type: text/plain, Size: 3881 bytes --]

First, I appreciate all your support.

I tried to convert from .pcap to .pppdump and use pppdump (with -p and -d)
to decompress the data.
But again, the output contains the same data as the compressed packets.
The files are attached.

I have some questions:

1 - I tried to use pppd with the recording option (pppd record
output.pppdump), but all it did was print
"~�}#�!}!}!} }4}"}&} } } } }%}&v��}<}'}"}(}">*~" over and over on the
terminal. Also, no output file was saved. Am I doing something wrong?

2 - How does pppdump know that he has to use deflate for decompression?

On Mon, 22 Dec 2014 07:34:31 -0500, James Carlson
<carlsonj@workingcode.com> wrote:
> 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!

[-- Attachment #2: packets.zip --]
[-- Type: application/zip, Size: 5425 bytes --]