tcpdump mailing list archives
Re: pcap_next() caplen is off by 14 bytes (L2 len)
From: "Aaron Turner" <synfinatic () gmail com>
Date: Tue, 20 Mar 2007 09:49:03 -0700
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.
Current thread:
- pcap_next() caplen is off by 14 bytes (L2 len) Aaron Turner (Mar 20)
- Re: pcap_next() caplen is off by 14 bytes (L2 len) Guy Harris (Mar 20)
- Re: pcap_next() caplen is off by 14 bytes (L2 len) Aaron Turner (Mar 20)
- Re: pcap_next() caplen is off by 14 bytes (L2 len) Guy Harris (Mar 20)
- Re: pcap_next() caplen is off by 14 bytes (L2 len) Aaron Turner (Mar 20)
- Re: pcap_next() caplen is off by 14 bytes (L2 len) Guy Harris (Mar 20)
- Re: pcap_next() caplen is off by 14 bytes (L2 len) Aaron Turner (Mar 20)
- Re: pcap_next() caplen is off by 14 bytes (L2 len) Aaron Turner (Mar 20)
- Re: pcap_next() caplen is off by 14 bytes (L2 len) Aaron Turner (Mar 20)
- Re: pcap_next() caplen is off by 14 bytes (L2 len) Aaron Turner (Mar 20)
- Re: pcap_next() caplen is off by 14 bytes (L2 len) Guy Harris (Mar 20)