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

[Guy Harris <guy () alum mit edu>]

Aaron Turner wrote:

> 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.

It was almost certainly captured on a Linux box - it's not the standard 
libpcap format, it's one of a number of alternate formats used by some 
Linux libpcaps (see wiretap/libpcap.c for a bit of discussion of that).

The issue is that the snapshot length in the file header is, for some 
reason, 14 bytes shorter than the *actual* snapshot length of the 
capture.  Ethereal/Wireshark ignores that value, but libpcap doesn't - 
it allocates a buffer large enough for the specified value, and discards 
packet data past that value.

This might have come up before.

Libpcap *could* just grow its buffer and read the data - correcting the 
snapshot length *ex post facto*.  However, any code that trusts the 
snapshot length value it gets after opening the file (by calling 
pcap_snapshot()) would be in for a rude surprise, getting a packet 
bigger than the biggest it was told the file would have.

Any program that *completely* trusts that value - e.g., by allocating a 
buffer that big, and blindly copying the full packet into it - would 
break if we changed that.  Programs that report errors on those packets, 
or programs that report an error and stop, would also be a bit disturbed.

(Ethereal/Wireshark allocates a maximum-sized buffer for packets, 
regardless of the snapshot length.)

So I'm not sure what the right thing to do here is.  One thing to do 
might be to write a "fixer" program that reads the file with a fake 
snapshot length of 65535 and writes it out with that snapshot length - 
or, if the snapshot length is worth saving in the file (e.g., to 
indicate what the limit was), do a two-pass scan.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.