Re: pcap files with file header snaplen < packet

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

On 12/5/06, Jefferson Ogata <Jefferson.Ogata () noaa gov> wrote:
> Aaron Turner wrote:
> > Storing (or processing) the snaplen seems to open the door for
> > problems with little benefit (the cost of wasting a few thousand bytes
> > or incurring the performance penalty of a realloc if the default is to
> > small).  Actually, if you took the snaplen as merely a hint to the max
> > stored packet size and did a realloc on demand, the problem would
> > appear to be solved rather gracefully.
>
> I see the benefit of not truncating as far as maximizing the utility of
> a pcap file that is slightly degenerate. On the other hand, I see one
> gnarly downside.
>
> If semantics were changed so that packets could be longer than snaplen,
> then legacy programs that rely on snaplen as a convenient upper bound on
> packet size will experience buffer overflows if pcap starts returning
> packets longer than snaplen.
>
> So I agree it would be better for libpcap never to have truncated
> packets in the past, but turning off that behavior now is possibly
> dangerous.

Perhaps I'm confused... how does an application using the libpcap API
get access to the snaplen?   I don't see any way to do that.
Furthermore, all the libpcap functions seem to return a pointer to the
packet buffer, and said buffer is allocated by libpcap, not the
application.  I guess I don't see the danger.

--
Aaron Turner
http://synfin.net/
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.