Re: [Wireshark-users] The capturefile appears to be damaged orcorrupt. (pcap: Fileshas 109736-byte packet, bigger than maximum of 65535)

[Joseph Laibach <jlaibach () schonfeld com>]

Sake/GV,
        I found the issue. Yesterday I un-installed Wireshark and WinPcap and rebooted. On the reboot, the system spit 
out an error that the virtual disk 1 was missing. Virtual Disk 1 is my data drive that I have been writing the captures 
to. This server is running on a Dell Poweredge 1950. The rest of my machines are HPs. I'm going to be replacing this 
machine with a HP as soon as one becomes available. The Dell gives no warning or indication that the drive is bad. I 
received a replacement drive this morning, reinstalled Wireshark and winpcap and I'm capturing and analyzing without 
issues so far.

Thanks for all of your help,

Joe

-----Original Message-----
From: Gianluca Varenni [mailto:gianluca.varenni () cacetech com]
Sent: Tuesday, May 18, 2010 1:52 PM
To: Joseph Laibach; Community support list for Wireshark; Sake Blok
Subject: Re: [Wireshark-users] The capturefile appears to be damaged orcorrupt. (pcap: Fileshas 109736-byte packet, 
bigger than maximum of 65535)

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 () schonfeld com>
Sent: Tuesday, May 18, 2010 5:56 AM
To: "Community support list for Wireshark" <wireshark-users () wireshark org>;
"Sake Blok" <sake () euronet nl>; <gianluca.varenni () cacetech com>
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 () wireshark org
> [mailto:wireshark-users-bounces () wireshark org] 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 () euronet nl>
> Sent: Monday, May 17, 2010 1:38 PM
> To: "Community support list for Wireshark" <wireshark-users () wireshark org>
> Cc: "Gianluca Varenni" <gianluca.varenni () cacetech com>
> 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 () wireshark org>
> Archives:    http://www.wireshark.org/lists/wireshark-users
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
>
> mailto:wireshark-users-request () wireshark org?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.



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.

___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request () wireshark org?subject=unsubscribe