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

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

Aaron Turner wrote:

> Not sure I follow the above.  What value are you talking about here...
> the file snaplen?

Yes.

> Not sure what errors you're talking about here.
> People should always compare the packet caplen/len to determine if the
> packet was truncated, not the file snaplen.

It's not a question of determining whether the packet was truncated, 
it's a question of whether the application assumes that no packet will 
have more captured data than the value of the snapshot length from the 
file header, and either

	1) blindly assumes that libpcap will ensure this - which libpcap 
currently does, although whether that's part of libpcap's contract with 
applications using it is another matter;

	2) treats any packet with more data as an error, and either complains 
and drives on or complains and gives up.

> One fix that would work w/o breaking backwards compatibility is to
> emulate Ethereal/Wireshark for pcap_open_offline().  Basically ignore
> the header snaplen, allocate the max size buffer and have
> pcap_snapshot() always return 65535 as well.  I suppose someone might
> assume that if snaplen > len, then len == caplen, in which case some
> software may break, but it would be an easy fix.

...although it would mean no file could use libpcap to determine what 
the purported snapshot length of the capture was.  The snapshot length 
is potentially useful - one could assume that len > caplen implies a 
snapshot length was used, although somebody might want to know what the 
actual specified length was.

With pcap-NG, there is no *file* snapshot length, there's only a 
snapshot length for a given interface; a future libpcap API that 
supports current libpcap and pcap-NG would encourage application writers 
to handle this better.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.