Re: problem with caplen<total len

[Guy Harris <guy () alum mit edu>]

On Fri, Oct 10, 2003 at 08:03:55AM -0400, Russ Fink wrote:
> I noticed if you use the "-s" option with the "-w" option in tcpdump, this 
> causes a pure truncate of packets which are then stored into the pcap file.  

Or even if you *don't* use it, as the default snapshot length is 68
bytes if you don't have IPv6 enabled and 96 bytes if you do.

> Earlier, I thought this was a bug, but the more I think about it, it's 
> really not.  A chop is a chop.  The original header data should not be 
> changed just because I'm collecting the packets differently.

Correct.  One reason for capturing packets with a snapshot length is
that you're only interested in, for example, the behavior of TCP, so you
capture only enough data to get the TCP headers and the headers before
it; cutting packets off at that length means not as much data is copied,
so there's a lower CPU requirement and lower memory buffering
requirement (and hence perhaps a lower chance of packets being dropped).
In that case, the user probably wants the contents of the IP header as is.

> My question now is, is there any utility you know of that can fix "broken" 
> pcap files - specifically, update the ip header length = caplen, and 
> recompute the various checksums?

I don't know of any.  One problem is that it's not "broken" - it's just
truncated - so that's not really a "fix".  Any application that's
reading the capture file and that expects the full packet payload to be
there won't necessarily work even if you set the IP total length to a
fake value, as the packets they're seeing aren't the packets on the
wire.

Why are the checksums and IP length not being faked a problem?  There's
probably a better way to solve the problem.
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:tcpdump-workers-request () tcpdump org?body=unsubscribe