[Guy Harris <gharris@xxxxxxxxxxxx>]

On Sat, Jun 24, 2000 at 11:51:06PM -0400, John J. LeMay Jr. wrote:
> I'm running Mandrake Linux 7.1 here and just installed Ethereal 0.8.9 from RPM.
> I receive the following error:
> 
> [root@logan jlemay]# ethereal 
> ethereal: error in loading shared libraries: ethereal: undefined symbol:
> snmp_set_full_objid
> 
> Anyone know where I should start looking to solve this problem?

At the Ethereal FAQ at

	http://ethereal.zing.org/faq.html

which has an entry for

	"Ethereal will not run because snmp_set_full_objid is an
	undefined symbol."

which links to

	http://ethereal.zing.org/faq.html#q3.4

where it says:

	Q: Ethereal will not run because snmp_set_full_objid is an
	undefined symbol. 

	A: You've upgraded to UCD SNMP 4.1.1, right? Or perhaps you're
	using RedHat 6.2.

	Either install UCD SNMP 4.0[.x] on your system, or download
	source code and built from source; UCD SNMP 4.1.1 removed from
	the library a routine that Ethereal calls (it changed it to a
	macro wrapper for another routine), and the RPMs for Ethereal
	are built on, I think, a pre-RH 6.2 system with the earlier UCD
	SNMP (as per the "-v" message), which means they won't work with
	systems such as RH 6.2 that have UCD SNMP 4.1.1.

It sounds as if Mandrake 7.1 corresponds to Red Hat 6.2.

Note that

	1) UCD SNMP 4.1.2 also fixes this bug

but

	2) if you install another UCD SNMP release (including a new
	   shared library), you need to make sure it *OVERWRITES* the
	   existing UCD SNMP - i.e., if, on your system, there are UCD
	   SNMP libraries in "/usr/lib", if the new shared libraries get
	   installed in "/usr/local/lib", Ethereal might still end up
	   using the old ones, unless you *remove* the old ones (e.g.,
	   by un-installing the UCD SNMP package that came with your
	   system)

and

	3) installing new shared libraries in place of the old ones
	   *should* obviate the need to download source and recompile -
	   but if you do download source and recompile, you also need to
	   make sure the old header files don't remain.

When Ethereal 0.8.10 comes out, and RPMs are built, those should work
correctly on systems with UCD SNMP 4.1.1 as well as other systems, as
the SNMP dissector currently in the CVS tree has a hack to try to make
procedure calls that are supported by the shared library you happen to
have on your system, so, with any luck, that particular FAQ entry will
no longer apply, just as, in the versions of Ethereal that are available
now, there are workarounds for

	Q: Under Linux, the program freezes while trying to do a live
	   capture.

	A: Ethereal uses the libpcap library to perform live captures. 
	   The stock libpcap doesn't implement a feature that returns
	   control to the calling application if the network is idle. 
	   There is a patch at http://ethereal.zing.org/~gerald that fixes
	   this behavior.

obviating the need to patch libpcap for Linux - in effect, Ethereal on
Linux itself does the "select()" that the patch adds - and for

	Q: I tried to open a tcpdump capture file under Red Hat 6.1, and it
	   blowed up real good.

	A: The version of libpcap/tcpdump that comes with RH 6.1 changed
	   the format of its capture files without changing its magic
	   number.  *As a result, these capture files are incompatible
	   with tcpdump, ethereal, and any other libpcap-aware program on
	   any other platform, including previous versions of Red Hat
	   Linux*.

	   The libpcap and tcpdump packages from Red Hat 6.0 appear to work
	   under Red Hat 6.1.  It might be a good idea to install these if
	   you want to play well with others.

	   As of version 0.7.8, Ethereal should be able to read this new
	   file format.

obviating the need to replace libpcap and tcpdump - the library Ethereal
uses to read capture files does a hack to try to recognize those capture
files (that particular RH bug has been fixed in 6.2, as the magic number
is now different from the standard one in their non-standard files, and
Ethereal/Tethereal/editcap also recognize that magic number).

(It might be interesting to see how many OS breakages we've had to work
around in Ethereal for various OSes; there are those three for Linux,
and there's the whole libz mess for the BSDs, for example.)