[Tcpick-project] Corrupt data with -wR

[Michael S. <mic...@gm...>]

Hi

I'm trying to use tcpick to restore transferred files from HTTP connections. For this I'm running tcpick like so:

$ tcpick -i en0 -ap -wR 'port http'

But most of the captured data is corrupted, similar to what was described by Penelope Fudd in KNOWN-BUGS. So I did some testing with capturing TCP streams containing test patterns and comparing the output of tcpick and Wireshark. I'm using netcat to send a file over a TCP connection that looks like this:

0------0------0------0------0------0------0------0------0------
1------1------1------1------1------1------1------1------1------
2------2------2------2------2------2------2------2------2------
...

I.e. 63 characters per line (plus a newline), each filled with the line number every 7 characters, 128 lines in total. The Python script to generate the file is attached. tcpick writes a file that is exactly 64 * 128 bytes long but every now and then some random data is inserted and some content is duplicated. The captured file is also attached.

It seems there is a Pattern to the corruption:

before byte 958: correct
before byte 1024: random
before byte 1982: correct
before byte 2068: random
before byte 2472: copy of data after 2472. (2472 is an estimate but seems fitting)
before byte 4030: correct
before byte 4116: random
before byte 4520: copy of data after 4520. (again, an estimate)
and so on ...

The pattern becomes evident if the byte positions are compared to the payload sizes of the transmitted TCP packets. These are, according to Wireshark:

packet 1: 1024 bytes
packet 2: 1448 bytes (2472 bytes total)
packet 3: 600 bytes (3072 bytes total)
packet 4: 1448 bytes (4520 bytes total)

It seems that packets 1, 2 and 4 have been captured at the correct position but the end of the payload (always starting at byte 958) has been corrupted by some random data and sometimes with data from the next packet (It seems fitting that packet 3 was too short to be corrupted). Sadly, this makes it impossible to use any of the data that's captured.

Im using tcpick 0.2.1, installed using MacPorts on Mac OS X 10.6.8 (which builds the 32-bit-version).

I hope this all helps to finding and fixing this bug, but if anyone needs any more information about my setup or wants me to run different tests, I'm very pleased to help! If you're trying to reach me a few months after I've written this message, it might be that I've unsubscribed from this list. So simply put me into your reply's CC so I'll get the message.

Thanks everyone!
Michael