Re: Fixing damaged cap file

[Alexander Dupuy <alex.dupuy () mac com>]

Petr Novák wrote:

> I sent You cut off my damaged cap file. Do not post this file to the 
> internet please. Could You have a look, why this whole file is not 
> succesfully passed? But it is better than nonpatched tcpdump.
>
> OK I add one thing. I do not know why my cap file is damaged. It was 
> generated by tshark and computer run without problems. Other caps are 
> good, I hope. But this damaged file is biggest one (about 500 MB). 
> Other caps has about 200 MB.

Looking at the first couple of packets with tcpdump -vex (verbose, show 
ethernet, and hexdump), I see the following:

15:32:22.395282 00:15:62:b4:08:ff > 00:0e:0c:5e:90:52, ethertype IPv4 
(0x0800),
length 60: (tos 0x0, ttl 58, id 27522, offset 0, flags [DF], proto TCP 
(6), length 40, bad cksum f404 (->210b)!)
   213.29.7.33.16384 > 13.10.202.250.20628:  tcp 16 [bad hdr length 4 - 
too short, < 20]
       0x0000:  4500 0028 6b82 4000 3a06 f404 d51d 0721
       0x0010:  0d0a cafa 4000 5094 f553 8329 05ee 8a50
       0x0020:  101b a515 1100 0000 0000 0000 0046
15:32:22.469990 00:15:62:b4:08:ff > 00:0e:0c:5e:90:52, ethertype IPv4 
(0x0800),
length 1434: (tos 0x0, ttl 58, id 27523, offset 0, flags [DF], proto TCP 
(6), length 1420, bad cksum ee9f (->1ba6)!)
   213.29.7.33.16384 > 13.10.202.250.20628:  tcp 1396 [bad hdr length 4 
- too short, < 20]
       0x0000:  4500 058c 6b83 4000 3a06 ee9f d51d 0721
       0x0010:  0d0a cafa 4000 5094 f553 8329 05ee 8a50
       0x0020:  101b a5b7 db00 0048 5454 502f 312e 3120
       0x0030:  3230 3020 4f4b 0d0a 4461 7465 3a20 5361
       0x0040:  742c 2032 3020 4a61 6e20 3230 3037 2031

The bad checksum and bad header length (in the captured IP and TCP 
headers) show that there is corrupt data, and the hexdump reveals the 
source.  Note in particular the 0d0a bytes  (this is CRLF).  This could 
be a source of problems if e.g. FTP had expanded 0a (NL) to 0d0a (CRLF), 
but the previous byte 21 (ASCII !) reveals the source of the corruption, 
which is sendmail.  You sent the file in an e-mail message with 
something like /usr/lib/sendmail ubu.petr@seznamcz < dumpfile and since 
sendmail will forcibly break long (>72 bytes) lines by inserting 
!<CR><LF>, your tcpdump file was corrupted.

As I said in my message, my patches allow for recovery from some simple 
and easily recovered types of corruption.  Sendmail line-breaking is not 
one of them, and it is actually quite hard to reconstruct the original 
file in this case.

@alex

--
mailto:alex.dupuy () mac com

-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.