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.
