Wireshark-users: Re: [Wireshark-users]	The	capturefile	appears	to	be	damaged	orcorrupt.	(pcap:	Fi
      
      
The problem is that neither Sake nor I know why the trace is corrupted. From 
the code it looks impossible that dumpcap generated such corrupted capture.
GV
--------------------------------------------------
From: "Joseph Laibach" <jlaibach@xxxxxxxxxxxxx>
Sent: Tuesday, May 18, 2010 5:56 AM
To: "Community support list for Wireshark" <wireshark-users@xxxxxxxxxxxxx>; 
"Sake Blok" <sake@xxxxxxxxxx>; <gianluca.varenni@xxxxxxxxxxxx>
Subject: RE: [Wireshark-users] The	capturefile	appears	to	be	damagedorcorrupt.(pcap:	Fileshas	109736-byte packet, bigger than maximum of 65535)
Sake/GV,
       I don't fully understand all of this. If I have it correct the 
packet being captured has the wrong packet length counter in its header or 
am I missing something else? Is this something that can be corrected or 
compensated for by capturing in a different way?
Thanks for the help,
Joe
-----Original Message-----
From: wireshark-users-bounces@xxxxxxxxxxxxx 
[mailto:wireshark-users-bounces@xxxxxxxxxxxxx] On Behalf Of Gianluca 
Varenni
Sent: Monday, May 17, 2010 4:59 PM
To: Sake Blok; Community support list for Wireshark
Subject: Re: [Wireshark-users] The capturefile appears to be damaged or 
corrupt. (pcap: Fileshas 109736-byte packet, bigger than maximum of 65535)
--------------------------------------------------
From: "Sake Blok" <sake@xxxxxxxxxx>
Sent: Monday, May 17, 2010 1:38 PM
To: "Community support list for Wireshark" <wireshark-users@xxxxxxxxxxxxx>
Cc: "Gianluca Varenni" <gianluca.varenni@xxxxxxxxxxxx>
Subject: Re: [Wireshark-users] The capturefile  appears to      be 
damaged orcorrupt.(pcap: Fileshas       109736-byte packet, bigger than 
maximum of 65535)
On 17 mei 2010, at 22:17, Gianluca Varenni wrote:
the phdr struct is passed on from capture_loop_cb to
libpcap_write_packet unaltered. So in my understanding pcap_dispatch
must have supplied a wrong value of phdr->caplen for it to to faultly
written to file. However this contradicts with the fact that the whole
packet is indeed written after the header, because the following code
should have trimmed the data to phr->caplen:
     nwritten = fwrite(pd, 1, phdr->caplen, fp);
This is what I was expecting. In the corrupted file, what the is value 
of
the "len" field?
The packet header is:
BE 47 F1 4B FF ED 0B 00 62 00 00 00 66 00 00 00
ie incl_len is 98, while orig_len is 102
Which is totally legal... I have no idea, apart from adding assertions in
the dumpcap code, hoping to spot something weird.
GV
And the packet data is:
01 00 5E 00 05 DD 00 12 DA 9F 79 1B 08 00
45 00 00 58 00 00 40 00 18 11 7F A4 C6 8C 36 87 E0 00 05 DD
7E 35 20 1D 00 44 9F 74
00 3A 00 8C 00 0F DF 77 02 16 2C E4 6B 01 01 00 02 16 2C E2 00 00 00 00 
00
05 30 20 00 00 00 07 00 05 2F 58 00 00 00 02 04 4E 45 52 43 41 48 00 00 
00
00 00 00 00 00 00 00 00 00 00
ie 14 bytes ethernet header, 20 bytes IP header, 8 bytes UDP header and 
60
bytes payload => 102 (0x66) bytes in total
Cheers,
Sake
___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe
This communication is for informational purposes only.  It is not intended 
as an offer or solicitation or as an official confirmation.  Market prices 
and other information are not guaranteed as to completeness or accuracy 
and are subject to change without notice.  Schonfeld Group reserves the 
right to monitor and review the content of all messages sent to or from 
this e-mail address.