Wireshark · Ethereal-dev: Re: [Ethereal-dev] Ethereal

[Guy Harris <guy@xxxxxxxxxx>]

> > The current version of Ethereal attempts to work around this, so its GUI
> > shouldn't freeze when capturing on a not-so-busy network.  If its GUI
> > does freeze when that happens, please send a note about this, indicating
> > which version of which distribution of Linux you're using, and which
> > version of libpcap you're using, to ethereal-dev@xxxxxxxxxxxx.
> 
> The version that comes with RH7.1 says in the Help/About dialog: 
> 
> "Ethereal 0.8.15 Compiled with GTK+ 1.2.8, with libpcap 0.4, 
> with libz 1.1.3, without SNMP".
> 
> I noticed the following on an idle network:
> 
> 1) The GUI appears to freeze during capture (windows are
>    not repainted if hidden and then re-exposed).

That's bizarre.  A *LONG* time ago, Ethereal depended on a behavior of
libpcap that it didn't exhibit on Linux (or on Solaris or HP-UX, for
that matter...), which could cause it to freeze during a live capture;
however, we changed it not to do so a long time ago.

Perhaps somebody at Red Hat "improved" the Ethereal they ship by
breaking our workaround for that?

Try downloading the Ethereal source and building that.

> 2) There's no option in the Capture Preferences to turn on 
>    live packet capture.  Only options are "Capture in promiscuous
>    mode", "Auto scrolling in live capture" and "Enable name
>    resolution".

If by "live packet capture" you mean "a capture where the
list-of-packets pane is updated as packets arrive" (as I infer you do,
from comment 3), there is an option there, but it's not called "live
packet capture" - as noted in Dave Frascone's mail, *all* captures are
live, so calling such a capture a "live packet capture" would be
confusing - it's called "Update list of packets in real time".

> 3) The command-line "-S" option both enables live capture and
>    prevents the GUI from freezing.

A libpcap problem that would cause a GUI hang when doing a non-"Update
list of packets in real time" capture should cause the window with the
packet counts and "Stop" button to hang when doing a "Update list of
packets in real time" capture, even if the main window dowsn't hang.

> 4) rpm claims libpcap isn't installed (probably statically
>    linked with ethereal in the RH distribution).

Sounds like a Red Hat "improvement".

> 5) Tried downloading the latest version RPM from ethereal.com
>    but couldn't install:
> 
> > error: failed dependencies:
> >         libcrypto.so.0   is needed by ethereal-0.8.17-1
> 
>   RH7.1 comes with openssl-0.9.6-3, which defines libcrypto.so.1
>   but no .0 ... can I just create another symlink for the .0
>   version, or has libcrypto's API changed enough for .1 to break 
>   ethereal?

Ethereal does not, in fact, use libcrypto; however, it does use the UCD
SNMP library, which, on some platforms, may, in turn, use libcrypto.

I don't know whether RPM's dependency mechanism computes the transitive
closure of the dependency relation when the RPM is built - which means
that if program A depends on version 0 of library B, which, in turn,
depends on version 0 of library C, the RPM would claim that program A
depends on version 0 of library C - or if it's smart enough to realize
that version 0.1 of library B might well depend on version 1 of library
C, so computing the transitive closure when building the RPM is a Bad
Idea.

If the former is the case, you've just discovered why computing the
transitive closure when building the RPM is a Bad Idea if, in fact, the
problem is that the libsnmp with which the RPM was built depends on
libcrypto.so.0 but the libsnmp in RH 7.1 depends on libcrypto.so.1.

Either that, or perhaps when the Ethereal binary was built, it was
explicitly linked with version 0 of libcrypto (the run-time linker used
in Linux distributions should support, when building shared libraries,
linking that library with another library, so that if you link a program
with a given shared library, when the program is run it'll not only link
in that shared library but will link in the shared libraries with which
that shared library was linked - *ALL* systems that use ELF should work
that way - so I'm not sure why Ethereal would have to be explicitly
linked with "-lcrypto" at all).

Try building from source.