On Wed, Mar 28, 2001 at 11:09:23AM +0200, Ph. Marek wrote:
> I'm having a problem with ethereal.
Ethereal as downloaded, in binary form, from the Ethereal Web site, or
Ethereal as compiled from source?
> It works very well with linux, but I have a problem in NT4: it thinks that
> the incoming packets (via olicom tr 3140) are frame type "ethernet II".
Have you installed WinPcap 2.1?
> If I uncheck "protocols/eth" it says "unsupported WTAP_PCAP=1".
>
> This is with the current binaries.
Current binaries of Ethereal (as in "binaries from the Ethereal Web
site"), current binaries of WinPcap (the current binary is 2.1, and your
later comment about wpcap.dll indicates that you might be using 2.1), or
both?
> So I downloaded the sources and tried to debug wpcap.dll, where such a
> check is performed - I thought, the switch: default -> Ethernet10MB is the
> case where it went wrong.
Probably.
> BUT: wpcap.dll is never used by ethereal!!!
Current binaries of Ethereal were built before WinPcap 2.1 was released.
Previous versions of WinPcap had only a static (".lib") version of the
libpcap/WinPcap library, not a dynamic (".dll") version.
As such, current binaries of Ethereal are linked with the static version
of the library - and will continue to use the code from that older
version of the library, *regardless of whether you've installed WinPcap
2.1 or not*.
Pre-2.1 versions of WinPcap didn't support Token Ring at all; I think
they'd refuse to let you start a capture on a Token Ring device.
The 2.1 version of the driver, however, will let you start a capture on
a Token Ring device.
However, it'll return, to the user-mode code that's using it, a
link-layer type of NdisMedium802_5; the older versions of the
libpcap/WinPcap library, in the switch statement to which you refer,
don't have a
case NdisMedium802_5:
case, so it will, indeed, fall through to the "default:" case, and map
it to DLT_EN10MB, for Ethernet.
The current CVS tree for Ethereal is set up to link with the "wpcap"
library, which means it should link it with "wpcap.dll".
The source to the 0.8.16 (and earlier) releases, however, is set up to
link with the "libpcap" library, which means that, if you've installed
the WinPcap 2.02 (or earlier) developer's pack, and haven't subsequently
removed the files it installed, and you try to build Ethereal from that
source code, you'll link with the old static "libpcap.lib" from WinPcap
2.02, and will produce an Ethereal binary that won't work with Token
Ring.
So, to get an Ethereal that can capture on Windows on a Token Ring
device, you would either have to:
1) get the current CVS tree for Ethereal (either with anonymous
CVS, or by downloading one of the nightly snapshots), get all
the tools you need on Windows to build it (the nightly
snapshots are gzipped tarballs, so you may want to get
CygWin:
http://sources.redhat.com/cygwin/
before downloading Ethereal, as you'll probably need stuff
from Cygwin to gunzip and untar the tarballs; you'll also
need stuff from Cygwin to *build* Ethereal), remove the
WinPcap 2.02 developer's pack if you have it installed,
install WinPcap 2.1 if you haven't installed it already (you
should uninstall 2.02, if you have it installed, before
installing 2.1), download and install the WinPcap developer's
pack, update "config.nmake" as appropriate (note that you'll
also need developer versions of GTK+ and GLib - see
http://www.ethereal.com/distribution/win32/gtk+-dev-20001226.zip
), read "README.win32" in the source tree, get everything to
which it refers that you don't already have, and build
Ethereal from there
or
2) wait for the next release of Ethereal and for Windows binary
versions to be made of that release
or
3) do all your capturing with WinPcap (which supports capture
filters - using the same syntax as Ethereal) - remember to
specify "-w" to save the capture to a file, and to specify "-s
65535" if you want more than the small 68 byte captures that
tcpdump/WinDump give you by default - and then read the
resulting capture files with Ethereal.