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

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

Aaron Turner wrote:

> Honestly, I can't imagine why the snaplen is interesting other then
> for properly sizing the packet data buffer,

It might be useful to use as evidence if somebody asks why a capture has 
only partial packets in it.

> Well the real issue IMHO is the buggy RH hacked libpcap.

...and, after looking at various versions of the hacked libpcap, it's 
obvious where the bug was coming from - the snapshot length was used in 
the recvfrom() call as the count, so up to that many bytes were 
received, but, if the capture was done in cooked mode, a fake Ethernet 
header is prepended, so the effective snapshot length is 14 greater than 
the one supplied to the program.

I've checked into the main and x.9 branches a change that sets the 
pcap_t's snaplen value to 14 more than the value from the file header if 
the capture was an Ethernet capture with the modified libpcap (based on 
the magic number).  This isn't ideal - I'd like to do it only if the 
capture was done in cooked mode - but there's no easy way to determine 
whether it was a cooked-mode capture or not, so, while that means that a 
raw-mode Ethernet capture will appear to have a snapshot length 14 more 
than the real snapshot, that's probably the best we can do.  That 
modified libpcap hasn't, as far as I know, been in any Linux 
distribution for a while, so there shouldn't be many *more* of those 
files showing up.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.