Re: Fixing damaged cap file

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

ubu.petr () seznam cz wrote:

> Please tcpdump, do not end, but run over damaged packets (move from
> current position in cap file byte by byte) from cap file until You find
> good header and packet,

Define "good".

The code *could* skip forward until it finds something that appears to 
have a caplen <= len <= 65535, but there's no guarantee that it would 
find a good header.

It could also check for a time stamp that looks "reasonable", for some 
definition of "reasonable", although there are some cases where, 
unfortunately, time stamps go backward in time.

Looking for a good packet is trickier, as it involves a lot of 
link-layer-type-dependent work.

 than go ahead. If this problem appears again,
> run over damaged packages again.
>
> With this patch file from You, I will compile tcpdump and will parse my
> big file successfully.

Define "successfully".  It will skip over bad packets, but whether it 
finds good packets is another matter.  If the file is damaged, the 
damage might occur in what appear to be "good" packets.  Consider, for 
example, a common form of damage - FTPing a file between Windows and 
UN*X in ASCII mode - which can insert or remove bytes in packet data.

Furthermore, it might skip over a lot of packets, meaning that the data 
you get from your capture file might be incomplete.

In other words:

	1) attempting to find a good packet by skipping file data is not easy, 
and is not guaranteed to find a real packet;

	2) if you do that, you lose a bunch of data from the file, so you're 
really not successfully reading the capture, you're getting a partial 
sample of the packets in the capture.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.