Wireshark · Wireshark-users: Re: [Wireshark-users] *.pcap file?

[hadi motamedi <motamedi24@xxxxxxxxx>]

On 8/25/12, Guy Harris <guy@xxxxxxxxxxxx> wrote:
>
> On Aug 24, 2012, at 9:13 PM, hadi motamedi wrote:
>
>> Dear All
>> To troubleshoot my case, I captured the following log file from my
>> linux server as the following:
>> #tcpdump -i any -s 1500 -vvv -w /tmp/mss0-pps.pcap
>> But my wireshark cannot open it, returning "unknown file format" .
>
> On what machine are you running Wireshark?  The Linux server on which you
> ran tcpdump, or some other machine?
>
> If the file is still present in /tmp on the Linux server, what does the
> command "file /tmp/mss0-pps.pcap" print when you run it on that server?
>
> If you are running Wireshark on a different machine:
>
> 	1) What OS is the other machine running - Windows, or some flavor of UN*X?
>
> 	2) Did you copy the file to the machine on which you're running Wireshark,
> or is it being exported over some remote file system such as NFS or SMB?
>
> 	3) If you copied it, how did you copy it?
>
> 	4) If that machine is running UN*X, or if it's running Windows and you have
> Cygwin installed, what does "file" print when you run it on that machine?
> (Run "file" from Cygwin if the machine is running Windows.)
>
>> Can you please let me know how can I recover this damaged file ?
>
> No, because we don't know what the problem is - but if, for example, it was
> copied from Linux to Windows with a program that thought it was copying a
> text file, and therefore "helpfully" converted the UN*X text file line
> ending (LF by itself) to the DOS/Windows text file line ending (CR-LF),
> then, unfortunately, it may or may not be able to repair it usefully.  The
> Web page for pcapfix:
>
> 	http://freecode.com/projects/pcapfix
>
> claims that it supports a -d flag that "force[s] packet detection inside the
> whole file, and repairs ascii-corruption pcap header (Unix->Windows).", but
> whether it can detect and repair damage to *raw packet data* caused by the
> LF-to-CRLF conversion is another matter.
>
> If you copied the file from Linux to Windows, and if the file is still on
> the Linux server, I'd suggest
>
> 	1) making sure nobody deletes it from the Linux server
>
> and
>
> 	2) try copying it in some fashion that *doesn't* "helpfully" translate UN*X
> to DOS/Windows line endings, but that just copies the raw bytes of the
> file.
>
> (By the way, the snapshot-length argument to "-s" includes everything in the
> packet, *including link-layer headers*, so 1500 is the *wrong* value to use
> in most if not all cases - for example, if you're capturing on an Ethernet
> device, it's 14 bytes too short to capture a full-sized Ethernet packet, and
> if you're capturing on the "any" device, it's 16 bytes too short to capture
> a full-sized Ethernet packet.  I would use 65535 or 65536 instead, as that
> should be big enough for most link-layer headers.
> ___________________________________________________________________________
> 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
>
Thank you very much for your help. Please be informed that I collected
the file on my centos server and then sftp it to my windows machine
that has wireshark running on it. I need to analyze the sccp portion
of this file on my windows machine. The file command on my centos
machine shows it as "data".