Re: pcap files with file header snaplen < packet

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

On 12/4/06, Jefferson Ogata <Jefferson.Ogata () noaa gov> wrote:

> I was merely suggesting that perhaps one of the several tools available
> for this purpose doesn't properly set snaplen on its output file to the
> max of all input snaplens.

That's likely the case.  Of course I have to wonder why libpcap even
stores the snaplen?  Why not just create malloc a buffer 65535 bytes
long (or pick another reasonable value) and validate that the capen <=
that size.  If not, realloc to the appropriate size.

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.

Basically, users don't understand why libpcap truncated their packet-
or in my case they don't understand why my application truncated their
packet.  People want things to "just work" and it's asking a lot for
most people look at hex dumps of their pcap's to understand why this
is happening.  And telling people "run this tool to fix your pcap" is
only useful if they know this is why it's broken.

Honestly, I haven't taken a close enough look to see what the effort
would be to "fix" this as I've described, but if I submitted a patch
would it be accepted?

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