Re: pcap files with file header snaplen < packet

[Jefferson Ogata <Jefferson.Ogata () noaa gov>]

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.

So, having said all that, I'll stay on the fence on this one.

-- 
Jefferson Ogata <Jefferson.Ogata () noaa gov>
NOAA Computer Incident Response Team (N-CIRT) <ncirt () noaa gov>
"Never try to retrieve anything from a bear."--National Park Service
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.