Re: pcap_next() caplen is off by 14 bytes (L2 len)

["Aaron Turner" <synfinatic () gmail com>]

Inline...

On 3/20/07, Guy Harris <guy () alum mit edu> wrote:
> Aaron Turner wrote:
>
> > notice the addtional 14 byes in the wireshark decode: "G SRC='http://";
>
> When you say "same packet", do you mean that you ran "tcpdump -XX" on a
> capture file, and ran Wireshark on the same capture file, and got the
> "packet dump example from tcpdump -XX" output from tcpdump and the "same
> packet from wireshark" output in the hex dump pane in Wireshark?

Both were from the same capture file.  You can get the pcap from here:

http://tcpreplay.synfin.net/trac/browser/trunk/test/test.pcap?format=raw

The packet in question is packet #12, but other packets where the
caplen != len show this as well.

> Or was one, or the other, of those a live capture?
>
> And how were those packets captured?

That's an excellent question.  The original pcap file is over 3 years
old, and honestly I don't remember.  My guess is that the packets were
most likely captured using tcpdump using the default snaplen on a
RedHat Linux box since that was my main development environment at the
time.   I honestly don't remember if I was using the RH provided
libpcap (I know there have been problems in the past) or one manually
compiled from source, let alone which version of libpcap it might of
been.  Of course, I may of captured the packets using Ethereal.

> Is your program doing a live capture or reading from a capture file?

Reading from a file.

> What snapshot length did you use when doing the capture or captures
> (snaplen argument in pcap_open_live, "-s" argument in tcpdump or TShark,
> whatever the dialog box says in Wireshark)?

Default snaplen when capturing the original file (no -s flag).

> > This only happens when pkthdr.len != pkthdr.caplen.  For the record,
> > this is libpcap 0.9.5 under OS X.
>
> Which OS X release?

10.4.9.  libpcap is from Darwin/OSX Ports.   For what it's worth, this
problem seems to affect both PPC & Intel mac's and most likely spans
multiple libpcap revisions based on the fact that my unit test cases
(which are also available in SVN) are showing this issue.

Anyways, in GDB, I looked at the pkthdr struct immediately after
pcap_next() and confirmed that it is returning a caplen which is 14
bytes shorter then Wireshark is reporting.

Thanks for looking into this...

--
Aaron Turner
http://synfin.net/
http://tcpreplay.synfin.net/ - Pcap editing & replay tools for Unix
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.