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:[EMAIL PROTECTED]
