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

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

On 3/20/07, Guy Harris <guy () alum mit edu> wrote:

[snip]

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

Honestly, I can't imagine why the snaplen is interesting other then
for properly sizing the packet data buffer, but it doesn't really
matter what I think. :)

Do you have any opinion on a pcap_override_snaplen() function?  Would
you accept a patch which implements it?   As I mentioned, a separate
binary to fix the pcap file really isn't useful since there's no good
means to detect this issue using the libpcap API.

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

Well the real issue IMHO is the buggy RH hacked libpcap.  If snaplen
> = caplen we wouldn't be having this conversation.   It would seem
that the bed has already been made, so encouraging applications
writers to handle this better is probably too late if you're not
comfortable with making the change now.

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