Summary pretty much says it. although ethereal and tcpdump are linked against the same libpcap, ethereal complains about a corrupt file when trying to read a file captured by tcpdump. You could say 'well ethereal just can't read tcpdump's files' - BUT the manual claims it can AND the official windows version can either! The only problem i could find anywhere was related to incompatible versions of libpcap - but on gentoo ethereal and tcpdump are linked against the same libpcap - so i'm out of clues where this could come from or if this is gentoo-specific. If you tell me so, i'll go file this problem upstream. i can provide a small tcpdump-file that cannot be read with ethereal (but can with tcpdump -r) Reproducible: Always Steps to Reproduce: 1. tcpdump -w test 2. ethereal test 3. watch ethereal bomb Actual Results: ethereal complains about corrupt file Expected Results: ethereal should do what Win32-Ethereal does: Read the file hel@hellap hel $ emerge info Portage 2.0.51.19 (default-linux/x86/2005.0, gcc-3.3.5, glibc-2.3.4.20041102-r1, 2.6.11-gentoo-r4-skas i686) ================================================================= System uname: 2.6.11-gentoo-r4-skas i686 Intel(R) Pentium(R) M processor 1400MHz Gentoo Base System version 1.4.16 Python: dev-lang/python-2.3.4-r1 [2.3.4 (#1, Feb 7 2005, 08:50:30)] ccache version 2.3 [disabled] dev-lang/python: 2.3.4-r1 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.5, 1.6.3, 1.7.9-r1, 1.4_p6, 1.9.4, 1.8.5-r3 sys-devel/binutils: 2.15.92.0.2-r1 sys-devel/libtool: 1.5.10-r4 virtual/os-headers: 2.6.8.1-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-Os -march=pentium3 -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-Os -march=pentium3 -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig distlocks sandbox sfperms" GENTOO_MIRRORS="http://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ http://www.gigaload.org/gentoo.org/ http://gentoo.inode.at/ ftp://gentoo.inode.at/source/" LANG="de_DE.utf8" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X acpi adns alsa apache2 arts artswrappersuid avi bash-completion berkdb bitmap-fonts cdparanoia cdr crypt cups curl dvd emboss fam foomaticdb gd gdbm gif glut gphoto2 gtk gtk2 imagemagick imlib innodb jpeg jpeg2k kde kdeenablefinal ldap libg++ libwww mad mikmod mmx motif mozilla mozsvg mp3 mpeg mysql nagios-dns nagios-ntp nagios-ping nagios-ssh ncurses nls nologin nptl offensive oggvorbis opengl pam pda pdflib pic png qt quicktime readline real rtc samba sdl slang snmp spell sse sse2 ssl svg tcpd tiff truetype truetype-fonts type1-fonts unicode userlocales wifi wmf xinerama xml2 xscreensaver xv xvid zlib linguas_de" Unset: ASFLAGS, CBUILD, CTARGET, LC_ALL, LDFLAGS
i cant reproduce the problem, what versions are you using? me: ethereal-0.10.10 tcpdump-3.8.3-r1 Lilith marco # emerge info Portage 2.0.51.19 (selinux/2004.1/x86, gcc-3.3.5, glibc-2.3.4.20040808-r1, 2.6.10-hardened-r3 i686) ================================================================= System uname: 2.6.10-hardened-r3 i686 Intel(R) Pentium(R) 4 CPU 2.00GHz Gentoo Base System version 1.6.9 Python: dev-lang/python-2.3.4-r1 [2.3.4 (#1, Feb 16 2005, 22:47:46)] distcc 2.16 i386-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] dev-lang/python: 2.3.4-r1 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.5, 1.8.5-r3, 1.6.3, 1.4_p6, 1.7.9, 1.9.4 sys-devel/binutils: 2.15.92.0.2-r1 sys-devel/libtool: 1.5.10-r4 virtual/os-headers: 2.4.21-r1 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O2 -mcpu=i386" CHOST="i386-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -mcpu=i386" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox selinux sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X berkdb cdr crypt cups curl esd fam flac gdbm gif gtk imagemagick imlib java libwww motif mysql ncurses nls oggvorbis opengl pam perl png python qt readline selinux snmp sqlite ssl tcltk tcpd tiff x86 xml xml2 xmms zlib" Unset: ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS
libpcap-0.8.3-r1 tcpdump-3.8.3-r1 ethereal-0.10.10 i'll go attach the dumpfile that doesn't work on my ethereal.
Created attachment 55250 [details] Example dump file that does not work
it works here ...
good for you :) I'll try recompile ethereal with CFLAGS=-O2 -march=i386 and see if it makes a difference.
No luck, tried several combinations of CFLAGS... always the same error: The capture file appears to be damaged or corrupt. (pcap: File has 1623838720-byte packet, bigger than maximum of 65535) I also tried remerging libpcap a few times and i'm running out of ideas...
*** Bug 87896 has been marked as a duplicate of this bug. ***
Heiko, please use text/plain when submitting text attachements.
sorry, but this IS a binary attachment (tcpdump format)
err sorry I missed that.
I get the same error but not trying to read tcpdump files. It happens when I try to use ethereal to capture packets on it's own. I found a gentoo forum post and USE=-snmp solved the problem for them (did it for me too).
true. with snmp-support ripped out, ethereal can read the tcpdump-format again.
USE="snmp" emerge ethereal and it still works for me
if ethereal-0.10.11 still fails attach ethereal -v and I'll report this upstream.
it it fixed in the latest version?
I'll check this week - really short on time right now
k the new version works fine for me :)