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! -- James Carlson 42.703N 71.076W <carlsonj@xxxxxxxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-ppp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
