On Tue, 21 Nov 2000, Guy Harris wrote:
> > Subject: Bug#77655: ethereal: Doesn't support tokenring on 2.4.0-testx; but does on 2.2.x
>
> A more detailed description than "doesn't support tokenring" might be
> helpful here. What does it do instead of supporting token ring?
heh... Unfortunately one can not cut&paste from the ethereal error panel
;-{
The message (paraphrased) is that the capture session could not be
started because of an unknown physical layer type 0x320. Please
make sure you have sufficient permissions, and that you have the proper
interface specified.
> Also, which version of Ethereal is this? It's probably not the latest
> version, and may have had various changes made to it by the Debian
> maintainer.
Ethereal 0.8.13, gtk+ 1.2.8, libpcap 0.4a6, libz 1.1.3, snmp 4.1.1
> > I'm not sure, but this may be a libpcap0 bug instead...
>
> Does the version of tcpdump in Woody support token ring?
I believe so
> If so, does it work with the 2.2.x kernel?
Yes, iirc
> If so, does it work with the 2.4.0-textX kernels?
No:
$ tcpdump -i tr0
tcpdump: unknown physical layer type 0x320
> If the answers are "yes", "yes", and "no", it's almost certainly a
> libpcap problem.
>
> I might suggest trying the latest CVS version of libpcap from
> tcpdump.org; unfortunately, on UNIXes that come with a shared-library
> version of libpcap, replacing it with a version from tcpdump.org is
> probably a royal pain, as the tcpdump.org version doesn't build shared
> libraries, and, even if you configure it to install on top of the
> existing libpcap (rather than putting it under "/usr/local"), it'll
> leave the old shared library around, meaning that if you try to build
Hrm... Thanks for the sanity check - I'm not really surprised that it
looks more like a libpcap problem.
Next week I'll see if I can pull a recent libpcap source and
plug it into an extant debian package source.
--
Rick Nelson
Life'll kill ya -- Warren Zevon
Then you'll be dead -- Life'll kill ya