Re: [Tcpick-project] Corrupt data with -wR

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

On 2012-W05-1, at 13:36, Michael Schwarz wrote:

> 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!

I've given a shot at finding the problem myself. This is how far I got:

pcap calls got_packet() in loop.c for each captured packet. hdr-> len contains the length of the captured packet, hdr->caplen supposedly contains the amount of bytes that have been captured and are available under *packet. So I've put the following line at the beginning of got_packet():

printf("got_packet(): %p, %d, %d\n", hdr->caplen, hdr->len);

And got this output (only showing packets containing user data):

...
got_packet(): 0x5ea, 1514, 1024
got_packet(): 0x29a, 666, 1448
got_packet(): 0x5ea, 1514, 600
got_packet(): 0x29a, 666, 1448
got_packet(): 0x5ea, 1514, 600
got_packet(): 0x29a, 666, 1448
got_packet(): 0x442, 1090, 600
...

It seems that some of the packets are truncated, even though I do not understand why caplen is sometimes larger than len.

pcap_open_live() is called in tcpick.c to open the capture device. There, BUFSIZ is given as an argument to the snaplen parameter, which denotes the maximum number of bytes to capture of each packet. BUFSIZ is defined in stdio.h and is set to 1024 on my system. This obviously explains the truncated packets.

So I've set snaplen to BPF_MAXBUFSIZE instead, which is 2^15 on my system. This actually prevents the captured packets from being truncated, even though the output of the inserted printf does not change.

This seems to solve the problem, but it would be nice to know when a packet has been truncated and e.g. have the resulting stream not written to a file (maybe configurable via an option).

Michael