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@xxxxxxxxxxxxxxx> wrote: > On 12/21/14 13:37, Michael Richardson wrote: >> James Carlson <carlsonj@xxxxxxxxxxxxxxx> 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: packets.zip>>
