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

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

Well here's a quick patch (against CVS:HEAD) implementing
pcap_snapshot_override().  I did a quick test and it solves my
specific problem.  If you accept it, let me know if you decide to keep
the function name, so that I can make sure my code is forwards
compatible.  If there's anything you don't like, let me know and I'll
be happy to fix it.

Thanks,
Aaron

--
Aaron Turner
http://synfin.net/
http://tcpreplay.synfin.net/ - Pcap editing & replay tools for Unix


On 3/20/07, Aaron Turner <synfinatic () gmail com> wrote:
> 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.