FAQ

      Frequently Asked Questions (FAQ) for the UCD SNMP package
      =========================================================
		       FAQ Author: Dave Shield
		      ucd-snmp Version: 4.0.pre5
		ucd-snmp Project Author: Wes Hardaker
		Email: ucd-snmp-coders@ucd-snmp.ucdavis.edu

TABLE OF CONTENTS
=================

 TABLE OF CONTENTS
 GENERAL
   What is it?
   Where can I get it?
   What documentation is available?
   Are there binaries available?
   Where can I get the perl SNMP package?
   What operating systems does it run on?
   What happens if mine isn't listed?
   Does it run on Windows?
   How do I find out about new releases?
   How can I find out what other people are doing?
   How do I submit a patch or bug report?
   What's the difference between SNMPv1, SNMPv2 and SNMPv3?
   What are all these different SNMPv2's anyway?
   Which versions of SNMP are supported in this package?
   Where can I find more information about network management?
   Is ucd-snmp year 2000 (Y2K) safe?
   Is ucd-snmp thread safe?
 APPLICATIONS
   How do I add a MIB?
   How do I add a MIB to the tools?
   Why can't I see values in the <INSERT ENTERPRISE HERE> tree?
   I've done that, and I still can't see the values. Why not?
   I've done that, and I'm *still* not getting anything back. Why not?
   I've done that, but I'm *still* getting "sub-identifier not found:" Grrr!
   Why do I sometimes get "End of MIB" when walking a tree, and sometimes not?
   I can't load any of the mib files, and they seem to be missing
       the first two characters of the filename.  What's happening?
   I cannot set any variables in the MIB.
   Variables seem to disappear when I try to set them.  Why?
   Where can I find a MIB compiler?
   How do I handle traps and notifications?
   How do I use SNMPv3?
   Applications complain about entries in your example 'snmp.conf' file.  Why?
 AGENT
   What MIBs are supported?
   How do I add a MIB to the agent?
   How do I add functionality?
   What's the difference between 'exec', 'sh' and 'pass'?
   How do I write C code to integrate with the agent?
   What traps are sent by the agent?
   When I run the agent it runs and then quits without staying around. Why?
   How can I stop other people getting at my agent?
   I don't understand the new access control stuff - what does it mean?
   What ASN.1 parser is used?
   How does the agent fetch the value of a variable from the system?
   Why can't I see values in the UCDavis 'extensible' tree?
   Why can't I see values in the UCDavis 'memory' tree?
   What does "klread:  bad address" mean?
   What does "nlist err:  wombat not found" (or similar) mean?
   How about "Can't open /dev/kmem"?
   The agent is complaining about 'snmpd.conf'.  Where is this?
   Sometimes I seem to get the wrong answers.  Why?
   Why have some variables disappeared from the agent?
   The system uptime (sysUpTime) returned is wrong!
   The Host Resources information is wrong (and/or doesn't even compile)!
   What is the Official Slogan of the ucd-snmp-coders list?
 PERL
   How do I install the Perl SNMP module?
   Compiling this fails with "`MAX_NAME_LEN' undeclared"?
   I'm trying to use mib2c (or tkmib) and it can't locate SNMP.pm?
   I'm trying to use tkmib and it can't locate Tk.pm?
 PROBLEMS
   Why aren't my mib files read in any more?
   I'm getting answers, but they're all numbers. Why?
   The parser doesn't handle comments properly. Why not?
   How can I get more information about these MIB file problems?
   What's this about "too many imported symbols"?
   How do I compile with 'gcc' instead of 'cc'?
   But gcc doesn't compile it successfully on my new Solaris system. Why not?


GENERAL
=======

What is it?
----------

  - Various tools relating to the Simple Network Management Protocol
    including:

	* An extensible agent
	* An SNMP library
	* tools to request or set information from SNMP agents
	* tools to generate and handle SNMP traps
	* a version of the unix 'netstat' command using SNMP
	* a graphical Perl/Tk/SNMP based mib browser

    This package is originally based on the Carnegie Mellon University
    SNMP implementation (version 2.1.2.1), but has developed significantly
    since then.



Where can I get it?
------------------

WWW:
  - http://ucd-snmp.ucdavis.edu

FTP:
  - ftp://ucd-snmp.ucdavis.edu/ucd-snmp.tar.gz
  - ftp://sunsite.cnlab-switch.ch:/mirror/ucd-snmp/ucd-snmp.tar.gz
  - ftp://ftp.win.or.jp/pub/network/snmp/ucd-snmp/ucd-snmp.tar.gz
  - ftp://ftp.chg.ru/pub/networking/management/snmp/ucd-snmp/ucd-snmp.tar.gz



What documentation is available?
-------------------------------

	This FAQ (!)
	README
	INSTALL
	PORTING
	EXAMPLE.conf
	man pages for the individual tools, files and the API
	A guide for extending the agent

      Most of this documentation (plus archives of the mailing lists)
	 is also available on our web page:

        	http://ucd-snmp.ucdavis.edu



Are there binaries available?
----------------------------

  - There are binaries for some systems available in the binaries
    directory on the ftp site.



Where can I get the perl SNMP package?
-------------------------------------

  Joe Marzot's excellent perl SNMP module, which requires the ucd-snmp
  library, can be found at any Comprehensive Perl Archive Network
  (CPAN) site mirror in modules/by-module/SNMP.  To find the CPAN site
  nearest you, please see http://www.cpan.org/SITES.html.

  Consult the README file in the SNMP perl module distribution to find 
  out what version of the ucd-snmp library it needs to be linked against.

  See also the 'PERL' section later in this FAQ.



What operating systems does it run on?
-------------------------------------

  Both the applications and the agent have been reported as running
  (at least in part) on the following configurations:

	* HP-UX 9.07, 9.05, 9.03, 9.01 on HPPA 1.1 systems
	* HP-UX 10.20, 10.10, 10.01 on HPPA 1.1 systems
	* Ultrix 4.5, 4.4, 4.3, 4.2 on DEC MIPS systems
	* Solaris 2.6, 2.5.1, 2.5, 2.4, 2.3 on Sun SPARC systems
	* Solaris 2.5 on x86 systems
	* SunOS 4.1.4, 4.1.3, 4.1.3, 4.1.2 on Sun SPARC systems
	* OSF 4.0, 3.2 on DEC Alpha systems
	* NetBSD 1.3alpha, 1.2.1, 1.2, 1.1, 1.0 on all? systems
	* FreeBSD 3.0, 2.2.2, 2.2 on all? systems
	* BSDi 2.1 on all? systems
	* Linux 2.1, 2.0, 1.3 on all? systems
        * AIX 4.1.5, 3.2.5 on all? systems
        * OpenBSD ? on all? systems
        * Irix 5.1, 6.2
        * Windows95
        * Windows NT

  Note that agent support on Windows systems is likely to be somewhat
  less complete than on various flavours of Unix, due to the very
  different nature of the underlying operating system.
    (There's more that can be shared between the Unix implementations.
  Windows tends to need a completely separate approach)

  Also note that the presence of a particular configuration in this
  list does not imply a perfect or complete implementation.  This is
  simply what various people have reported as seeming to work. (Or more
  frequently, the configurations people have reported problems with!)



What happens if mine isn't listed?
---------------------------------

  It's worth trying anyway, particularly if the system is based
	around the BSD kernel.  If it seems to work correctly,
	let us know so that we can update the list above.
	If it doesn't work, let us know and we'll try to help.
  If the agent almost compiles, but certain files in the
	agents/mibgroup directory structure fail, you can try omitting
	the relevant modules by re-running configure with the flag
		--with-out-mib-modules="list"
	(where "list" is a space-separated list of modules to omit)
	You'll then need to re-compile.

	Note that with release 3.5, the structure of the mibgroup directory
	has changed, and this may affect how you specify this list.

  Either way, try it and let us know how you get on (see below for how).
	


Does it run on Windows?
----------------------

  The basic suite should now compile and run on Win32 platforms.
  This includes the library and command-line tools (apart perhaps
  from 'snmpdtrapd').
    The basic architecture of the agent builds, but the MIB-II
  (and other) modules do not (which rather negates the point!).
  Volunteers to assist in implementing Windows versions of these
  modules are likely to welcomed with open arms :-)

    Further details of Windows support (currently Visual C++ and
  Cygnus cygwin32) is available in the file README.win32



How do I find out about new releases?
------------------------------------

  There is a mailing list for these announcements
  	ucd-snmp-announce@ucd-snmp.ucdavis.edu
  To be added to (or removed from) this list, send a message
  to the address 'ucd-snmp-announce-request@ucd-snmp.ucdavis.edu'
  with a subject line of 'subscribe' (or 'unsubscribe' as appropriate).

  Major code revisions may be announced more widely (e.g. on the
	SNMP mailing lists, or comp.protocols.snmp) but this list is
  the most reliable way to keep in touch with the status of this package.

  Patches to fix known problems are also made available via the web site:
        http://ucd-snmp.ucdavis.edu/ucd-snmp-patches



How can I find out what other people are doing?
----------------------------------------------

  There is a general purpose discussion list
  	ucd-snmp@ucd-snmp.ucdavis.edu
  To be added to (or removed from) this list, send a message
  to the address 'ucd-snmp-request@ucd-snmp.ucdavis.edu'
  with a subject line of 'subscribe' (or 'unsubscribe' as appropriate).

  To find out what the coders are doing, and to help them out, please
  read the PORTING file enclosed with the package.



How do I submit a patch or bug report?
-------------------------------------

   There is a script that you can use to submit a bug report.
   This allow you to describe the problem you're having, and
	includes various pieces of information about your system
	that are useful in trying to track down the problem.

   Alternatively, you can send a message to
		'ucd-snmp-coders@ucd-snmp.ucdavis.edu'
	containing a description of the problem, and as much other
	relevant details as you can. Useful information includes the
	version of the package that you've been working with, the output
	of the command 'uname -a', the precise command that triggers the
	problem and a copy of the output it produces.

   We can't promise to be able to solve the problem, but we'll
	certainly try and help.


   If you're trying to port the package to a new system, the output
	of the command 'make -k' is a good starting indicator of where
	the bulk of the work is likely to be needed.

   If you're reporting success on a new system, please let us know
   both details of the hardware you're using, and what versions of
   the operating system you've tried it on.  The entry 'host' in
   the file 'config.status' will show this information.
	Oh, and congratulations!



What's the difference between SNMPv1, SNMPv2 and SNMPv3?
-------------------------------------------------------
What are all these different SNMPv2's anyway?
--------------------------------------------


  A full description is probably beyond the scope of this FAQ.
  Very briefly, the original protocol and framework was described
  in RFCs 1155-1157, and is now known as SNMPv1.

    Practical experience showed up various problems and
  deficiencies with this, and a revised framework was developed to
  try and address these.  This was described in RFCs 1441-1452, and
  is known as "SNMPv2 classic".
  The changes proposed include:

	* new ways of defining information (MIB structure)
		(SMI, Textual conventions, conformance statements)
	* new protocol packet types and transport mappings
	* new mechanisms for administration and security
	* mechanisms for remote configuration

  Unfortunately, while many of these were generally accepted, there
  was some disagreement in these last two areas, security/admin
  and remote configuration.  This resulted in a number of variants and
  alternative proposals:

	SNMPv2c		Contains the new protocol and MIB structure elements,
			using the existing SNMPv1 administration structure.
			This is the agreed SNMPv2 standard (described in
			RFCs 1901-1908), superseding SNMPv2 classic, and is
			known as "Community-based SNMPv2" or simply "SNMPv2".


	SNMPv2 usec	} Alternative proposals to address the
	SNMPv2*		} limitations of SNMPv1 administration
			} These are both super-sets of SNMPv2c

			
	SNMP-NG		An attempt to reach agreement between
			the proponents of usec and v2star.

  The formal successor to the SNMP-NG work has been termed SNMPv3.
  This has now been effectively finalised, and as been published as
  Proposed Standards.  This is described in RFCs 2571-2575.



Which versions of SNMP are supported in this package?
----------------------------------------------------

  This package currently supports the original SNMPv1, Community-based
  SNMPv2 (i.e. RFCs 1901-1908), and SNMPv3 (i.e. RFCs 2271-2275).
    The agent will respond to requests using any of these protocols,
  and all the tools take a command-line option to determine which
  version to use.

  Support for SNMPv2 classic (a.k.a. "SNMPv2 historic" - RFCs 1441-1452)
  has now been dropped.  Those still requiring this functionality should
  continue to use the v3-line of the UCD suite.  However, please note that
  it is unlikely that there will be any continued support of this line.



Where can I find more information about network management?
----------------------------------------------------------

  There are a number of sites with network management information on
  the World Wide Web. Two of the most useful are

      http://netman.cit.buffalo.edu/index.html
      http://wwwsnmp.cs.utwente.nl/

  There are two Usenet newsgroups which are relevant.
	'comp.dcom.net-management'
		which discusses general issues relating to network management
	'comp.protocols.snmp'
		which is specifically concerned with use of SNMP in particular

  (though there is a large overlap between these two groups).
  The SNMP group also has an FAQ (split into two parts) which discusses more
  general issues related to SNMP, including books, software, other sites,
  how to get an enterprise number, etc, etc.
  This is available from

      ftp://rtfm.mit.edu/pub/usenet/comp.protocols.snmp/

  or via either of the two Web sites above.


Is ucd-snmp year 2000 (Y2K) safe?
--------------------------------

  The ucd-snmp toolset stores all of its dates in the standard posix
  fashion supported by most operating systems: as seconds since
  1st Jan 1970.  Information stored this way is year 2000 safe.
  (Note that on 32-bit systems, this will overflow in the year 2038)

  Note that the suite will use assorted system library routines, so is
  clearly vulnerable to any year 2000 problems with these.

  Yes, ucd-snmp is year 2000 safe, as long as your operating system is as well.


Is ucd-snmp year thread safe?
----------------------------

  Strictly speaking, no.  However, it should be possible to use the
  library in a thread-safe manner.  This is covered in detail in the file
  README.thread (shipped with the standard distribution), but can be
  summarised as follows:

    -	Call 'snmp_sess_init()' prior to activating any threads.
	This reads in and parses MIB information (which isn't thread-safe)
	as well as preparing a session structure for subsequent use.

    -	Open an SNMP session using 'snmp_sess_open()' which returns an
	opaque session handle, which is essentially independent of any
	other sessions (regardless of thread).

    -	Resource locking is not handled within the library, and is the
	responsibility of the main application.





APPLICATIONS
============

How do I add a MIB?
------------------

  This is actually two separate questions, depending on whether you
  are referring to the tools, or the agent (or both).
    See the next question or the next section respectively.



How do I add a MIB to the tools?
-------------------------------

  The tools only really use the MIB files for translating between
  numeric and textual forms for queries and responses.  They will
  operate quite happily without any MIB files at all, as long as
  you are prepared to work with numeric OIDs throughout.
    The one exception to that is 'snmptable', which does require
  the relevant MIB file to be loaded.

  The tools look in a predefined directory (usually PREFIX/share/snmp/mibs)
  and regard any file held there as defining a MIB module or modules.
  Adding translation ability for a new MIB module is simply a
  matter of placing a file defining the MIB in this directory, and
  defining a suitable environment to tell the tools about it.
    (See the first question under 'PROBLEMS' for more details).

  The tools can then be used to communicate with any agent that
  implements the relevant MIB modules.

  The UCD agent, however, does not use these MIB text files at all, and
  will work quite happily without them.  (Actually it needs to find the
  main MIB file, though it doesn't do anything with it!).  The values
  returned by the agent are simple numeric (or string) responses, and
  the syntax and scope of the variables supported are hard-coded into
  the implementation.  The MIB text files are only used to translate
  these responses into more meaningful terms.



Why can't I see values in the <INSERT ENTERPRISE HERE> tree?
-----------------------------------------------------------

  Normally, the tools assume that any object ID specified is
  a full path, starting from the 'mib-2' node of the overall
  MIB tree.  So if you perform an 'snmpwalk' on an agent, without
  specifying a starting point, it will return just the values in
  the 'mib-2' tree.

    If you wish to examine anything under the 'private.enterprises'
  branch (or anywhere else in the MIB structure) you will need to
  inform the tools appropriately.   There are two ways to do this:

  First, you can give the full specification, starting from the root
  of the tree - e.g:

	.iso.org.dod.internet.private.enterprises.ucdavis

  Note the initial dot - this is important!


  Alternatively, you can define the environmental variable PREFIX,
  to specify where to start looking for ( non-fully specified) objects.
  This can be done by the command
							(C shell family)
	setenv PREFIX  .iso.org.dod.internet.private.enterprises.ucdavis
  or
							(Bourne shell family)
	PREFIX=.iso.org.dod.internet.private.enterprises.ucdavis
	export PREFIX

  after which, the following example should work:

	snmpwalk -v 1 localhost public processes



I've done that, and I still can't see the values. Why not?
---------------------------------------------------------

    Another possibility is that there is a clash of names
  somewhere within the MIB tree.  Try running the command
  'snmptranslate -w zzz' which will inform you of any duplicates,
  or other similar problem.

    This should be less of a problem with the new parser, which
  now handles duplicate identifier names, though inconsistent
  case in labels (or different names) for the same node still
  confuse the poor darling.



I've done that, and I'm *still* not getting anything back. Why not?
------------------------------------------------------------------

  Another possibility is that the agent you are querying is simply not
  responding.  Try contacting it with a "reliable" query.
  A good test is to do an 'snmpwalk' on the 'system' sub-tree.

    Or it may be that the agent just doesn't implement the MIB
  module that you're interested in.  Or it does, but is falling over
  (software with bugs in - shock horror!)
    Try doing an 'snmpwalk' starting somewhere above the offending bit
  of the MIB tree, and seeing how far it gets.

    Or the agent may not be configured to allow you access.
  One of the most common problems with the UCD agent is installing
  the example config file, but not changing the NETWORK field to
  match the local network address.  You also need to set a suitable
  string for COMMUNITY.
    See the access control question (in the AGENT section) for more details.




I've done that, but I'm *still* getting "sub-identifier not found:" Grrr!
------------------------------------------------------------------------

  If a "general" snmpwalk shows the entry, but asking for it more
  specifically gives a "sub-identifier not found:" error, then that's
  probably a slightly different problem.

    The tools assume that the object ID they are given is a full path
  starting from 'mib-2' (or wherever you have set PREFIX to) - i.e.
  including the intermediate names.
  You can't simply give the final sub-identifier, and expect the tools
  to find the relevant node.  (Well, you can, but you'll be disappointed).
    You need to specify the intermediate sub-identifiers as well.

    For example
		snmpget myhost public sysUpTime.0
                                                     will fail, while
		snmpget myhost public system.sysUpTime.0
                                                          will work.

    If you are confident that the sub-identifier is unique within the
  loaded MIB files, you can request direct "random access" using the
  command flag '-R'.
		snmpget myhost public -R sysUpTime.0
  
    If the sub-identifier is not unique, but you know which module it's
  in, you can specify this explicitly:

		snmpget myhost public -R RFC1213-MIB:sysUpTime.0

  The behaviour with non-unique sub-identifiers if the module is not
  specified is "implementation specific" 
	 (i.e. we reserve the right to change it without warning!)



Why do I sometimes get "End of MIB" when walking a tree, and sometimes not?
--------------------------------------------------------------------------

  This depends on which MIB modules are supported by the agent you are querying.

  A tree is walked by repeatedly asking for "the next entry" until all the
  values under that tree have been retrieved.  However, the agent has no idea
  that this is what's happening - all it sees is a request for "the next entry
  after X".

  If the variable X happens to be the last entry in a tree, the agent will
  provide the next variable supported (as requested) even though this will
  be in a different subtree.  It's up to the querying tool to recognise that
  this last result lies outside the area of interest, and simply discard it.

  If the variable X happens to be the last entry supported, then the agent
  doesn't have another variable to provide, so returns a suitable error.
  The UCD tools report this with the message above.

  But in either case, the actual information provided will be the same.



I can't load any of the mib files, and they seem to be missing
the first two characters of the filename.  What's happening?
-----------------------------------------------------------

  This is a problem experienced with Sun systems when the tools have
  been compiled with a mixture of BSD and Solaris environments.
  You'll need to re-configure and compile the tools, making sure that
  '/usr/ucb' is not in your PATH (or at least comes at the end).



I cannot set any variables in the MIB.
-------------------------------------

  There are three possible reasons for this:

  The majority of MIB variables are "read-only" and cannot be changed.

  Of those that can in principle be changed, only a few have been
  implemented as such in this agent.  Currently, most (if not all)
  of these are contained within the 'system' sub-tree, relating to
  general contact information.
    
  With the distribution as shipped, the community name "private" must
  be used to set these values, and this can only be done from the local
  host (i.e. the same system that the agent is running on).
    This can be changed using the access control commands, which appear
  at the end of the example config file.  For example, to allow write
  access to the 'system' group from the local subnet, with the community
  string "sysadmin", follow the instructions at the end of this example file.

    Note that the community string "public" can *not* be used to set variables.
  


Variables seem to disappear when I try to set them.  Why?
--------------------------------------------------------

  This is actually the same as the previous question - it just isn't
  particularly obvious.  A typical example of this effect would be

	$ snmpget localhost public system.sysLocation.0
	system.sysLocation.0 = somewhere nearby

	$ snmpset localhost public system.sysLocation.0 s "right here"
	Error in packet.
	Reason: (noSuchName) There is no such variable name in this MIB.
	This name doesn't exist: system.sysLocation.0

  This is due to the limitations of the available SNMPv1 error codes,
  which are forced to cover a number of different possibilities.
  What 'noSuchName' actually means is

	"You can't do that to this variable"

  That could be because the variable doesn't exist, it does exist but
  you don't have access to it (but someone else may do), or it exists
  but you can't perform that particular operation (i.e. changing it).

  The error codes in SNMPv2 (various flavours) are rather more flexible
  and informative:

	$ snmpset -v 2c localhost public system.sysLocation.0 s "right here"
        Error in packet.
        Reason: notWritable

  Note that this actually means "not writeable in this particular case",
  rather than "not writeable under any circumstances".  It may well be
  that a different invocation (such as using the community string "private")
  might be successful.



Where can I find a MIB compiler?
-------------------------------

  That depends what you mean by a "MIB compiler".  There are at least two
  types of tool that are commonly referred to by this name.

  The first is a tool to check MIB files for validity.  The functionality
  of this is mostly integrated within the MIB parser (part of the UCD library)
  and hence included in all the applications.  The tool 'snmptranslate' is
  probably the most appropriate for this purpose.
    Note that the parser is fairly forgiving (see 'What ASN.1 parser is used'
  below), so this should not be regarded as a stamp of approval.

    The second type of tool is one to turn a MIB specification into C code,
  specifically one designed to aid agent implementation.  There is an example
  of such a tool included within the 'local' directory, as 'mib2c'.
  See the next section for more information.



How do I handle traps and notifications?
---------------------------------------

    That depends on whether you need to send traps and notifications to
  a management station, or receive them from existing agents and handle
  them in some manner.

    Generating traps "by hand" can be done using the tool 'snmptrap'.
  An SNMPv1 trap needs to specify seven parameters:
	- the station to send to
	- the community name to use
	- the enterprise OID to send	(*)
	- the agent "sending" the trap	(*)
	- the generic trap type  (1-6 as defined in RFC 1157)
	- the specific trap type (0 if using generic traps 1-5)
	- the value of "uptime"		(*)

  The three parameters marked (*) can be left null (i.e. "") to use
  sensible default values.

    An SNMPv2 or v3 trap or notification (aka "inform") is simpler and
  just needs three (or four) parameters:
	- the station to send to
	- the community name	(SNMPv2c only)
	- the value of uptime	(or "")
	- the trap OID to send

    Either of these can then be followed by one or more (objectID type value)
  triples, using the same syntax as for 'snmpset'.


    Handling received traps is done using the tool 'snmptrapd'.  This can
  be used to log these traps (via 'syslog()' or printed to standard output)
  or pass them to an external command.
    See 'snmptrapd(8)' and 'snmptrapd.conf(5)' for details.
  


How do I use SNMPv3?
-------------------

    <Sigh>  We were hoping you wouldn't ask that!

    As far as the applications are concerned, this is simply a matter of using
  the "-v 3" option, and providing suitable values for the various SNMPv3
  parameters.  These are described in the snmpcmd(1) manual page.
    Configuring the UCD agent is less straightforward.  There is an initial
  description of how to do this in the file 'README.snmpv3', but this is more
  complex than we would like, and will hopefully be revised in the future.
    Also see the snmpusm(1) manual page, as it describes some basic
  information about how SNMPv3's user based security module works.
    Watch this space....
 


Applications complain about entries in your example 'snmp.conf' file.  Why?
--------------------------------------------------------------------------

    The example configuration file 'EXAMPLE.conf' is designed as a config
  for the agent, and should be installed as 'snmpd.conf' (note the 'd').
  The file 'snmp.conf' is intended for general configuration options,
  applicable to all applications (via the SNMP library).
    Rename (or merge) the 'snmp.conf' file to 'snmpd.conf', and this should
  fix the problem.



AGENT
=====

What MIBs are supported?
-----------------------

  The following MIBs are supported (at least in part):

	- MIB-2  General network statistics (RFC 1213)
	- UCD agent extensions
		(processes, disks, memory, load average,
		 shell commands, error handling)
	- SMUX implementation (RFC 1227) for communicating with 'gated'
		(plus routing protocols BGP, OPSF & RIP2 - RFCs 1657, 1724 & 1850)
	- Host Resources (RFC 1514) initial implementation

  The SNMPv2 Party and Manager-to-Manager MIBs (RFCs 1447 & 1451) have been
  withdrawn.



How do I add a MIB to the agent?
-------------------------------
How do I add functionality?
--------------------------

  Unfortunately, adding a file to the MIB directory does not automatically
  extend the functionality of the agent to include this MIB.  (Would that
  life were so simple).  In fact, the agent makes little or no use of
  these files, and will work quite happily without them.
  All the information about the syntax and scope of the variables supported
  is hardwired into the implementation of the agent.

  There are three ways to add functionality for a new MIB to the agent.

  Firstly, it is possible that the agent distribution already includes
  the desired functionality, but this has simply not been configured in
  to the running version.  This is done using the configure option
		--with-mib-modules="list"
  (where "list" is a space-separated list of modules to omit) then
  recompiling the agent.
  Note that some functionality concerned with monitoring and managing
  unix hosts is included in the UCD extension modules, which are located
  within the 'private' branch of the MIB tree.  This is covered in a later
  question in this FAQ.

  Secondly, it is possible for the agent to run commands or shell scripts
  in response to queries.  These can obtain and report the necessary
  information, or perform actions as required.
  Detailed information and examples are provided in the snmpd(1) and
  snmpd.conf(5) manual pages, and the EXAMPLE.conf file.
  This is known as "pass-through" support.

  Thirdly, the agent itself can be extended to support additional MIB
  groups, by writing the necessary C code.  This is covered further in
  the next question.

    Note that there is effectively no difference between 'pass-through'
  MIB support, and modules implemented within the agent itself. Tools
  querying the agent will see a single MIB structure.
 


What's the difference between 'exec', 'sh' and 'pass'?
-----------------------------------------------------

    'exec' will fork off the specified command and return the exit status
  and/or the output.  Arguments are passed directly to the command.

    'sh' is similar, but invokes a shell to run the command.
  This means that quoted arguments will be recognised as such, and also
  allows redirection, and other similar shell interpretation.

  Neither of these mechanisms require the command to have any knowledge
  of the fact that they are being used in this manner.  Note that return
  values are cached within the agent for 30 seconds, rather than invoking
  the command for every request.


    'pass' is a more general mechanism for extending the agent, and the
  command given will be invoked for any request within the specific MIB
  subtree.  Details of precisely how this command will be called in
  various circumstances is given in the 'snmpd.conf(8)' man page.

    'pass-persist' is similar, but the command will continue running
  even once the initial request has been answered.

  See 'snmpd.conf(5)' for more details.

  

How do I write C code to integrate with the agent?
-------------------------------------------------

  At the moment, there are two methods for integrating external C code
  within the agent.

    The first is to include this code within the agent itself, using the
  UCD agent API.  This is described (in excruciating detail) in the file
  AGENT.txt, shipped with the standard distribution.  There is also an
  HTML version accessible via the project web page.
    This task can be aided using the tool 'mib2c' which generates most
  of the necessary skeleton code from the description in the MIB file.
  Further information is also available in the files mibgroup/README
  and local/README.mib2c
  
    The second is to use an alternative API to communicate between the
  agent and an external management-enabled application.  One possibility
  is the SMUX protocol, which available as the module "smux" and is
  described in the file agent/mibgroup/README.smux.

    Alternatively, work is underway to implement AgentX support.  The
  initial implementation of this is available as the module "agentx",
  and is described in the file agent/mibgroup/agentx/README.  Note that
  the AgentX support is still very incomplete, and should be regarded as
  alpha code.  Don't even think about using this in a production environment!
  


What traps are sent by the agent?
--------------------------------

  The agent can be configured to send a 'coldStart(0)' trap when it first
  starts up.  The destination to send the trap to, and the community name
  to use, are set in the snmpd.conf file
    ('trapsink' and 'trapcommunity' respectively - note both are required)

    The agent can also be configured to send 'authenticationFailure(4)'
  traps when it receives SNMPv1 requests using a community name that is
  not recognised.
    This is done with the snmpd.conf entry 'authtrapenable 1'.
  (Note that the two 'trap' entries above are also still required).

    There is currently no easy way to extend the agent to send other
  traps or notifications.
    


When I run the agent it runs and then quits without staying around. Why?
-----------------------------------------------------------------------

  The first question is, are you certain that this is what is happening?

  The normal operation of the agent is to 'fork' itself into the
  background, detaching itself so that it will continue running even
  when you log out, and freeing the command line for subsequent use.
  This looks at first sight as if the agent has died, but using 'ps'
  to show all processes should reveal that the agent is still running.

  To prevent this behaviour (such as when attempting to debug the
  agent), you can start it with the '-f' flag.  This suppresses the
  fork, and the agent will run as a 'normal' command.

  On the other hand, if 'ps' shows that the agent is not running, then
  this is an error, and probably show that something went wrong in
  starting the agent up.  See under 'PROBLEMS' for more advice.  



How can I stop other people getting at my agent?
-----------------------------------------------

  First question - are you concerned with read access or write access?

  As far as changing things on the agent is concerned, there is very
  little that can actually be altered (see the answer to "I can't set
  any variables" under PROBLEMS, below).

    If you are using the example config file, this is set up to allow
  read access from your local network, and write access only from the
  system itself (accessed as 'localhost'), both using the community name
  specified.  You will need to set appropriate values for both NETWORK
  and COMMUNITY in this file before using it.
    This mechanism can also be used to control access much more precisely.
  (see the next question for details)

  Other options include:
	- Blocking access to port 161 from outside your organisation
		(using filters on network routers)
	- Configuring TCP wrapper support ("--with-libwrap")
		This uses the TCP 'libwrap' library (available separately)
		to allow/deny access via /etc/hosts.{allow,deny}



I don't understand the new access control stuff - what does it mean?
-------------------------------------------------------------------

  The idea behind the new access control model is to give a more flexible
  way of specifying who can see and do what within the MIB tree.
  It's more complicated to understand than the old community style, but
  that's because it can do a whole lot more.

    There are four configuration keywords in the new scheme:
	'com2sec', 'group', 'view', and 'access'

  We'll consider these one at a time, starting with 'access'.
  (Because I feel like starting with the last one, that's why - OK?)


  The "access" keyword has the job of specifying who has access to
  which bits of the MIB tree.  This has eight parameters, so can look
  rather offputting. Most of these can be safely left with default values
  in most cases (so don't you worry your pretty little head about them).
  The syntax is

	access {group} "" any noauth 0 {read-tree} {write-tree} {notify-tree}

  where the entries in braces need to be defined elsewhere (I'm coming
  to that - be patient!), and the rest can be left as shown here.

	[ If you really want to know, the 'sec.model' field can be used
	  to have an access line that's only relevant to particular
	  versions of SNMP (such v1 or v2c) rather than "any" version,
	  and the 'sec.level' field can be used to ensure that the
	  request is authenticated or encrypted.
	    You'll have to ask Niels about the other two!]


  The "view" keyword is used to define particular bits of the MIB tree,
  for use in the last three field of the access entry.
  This has the syntax

	view  {name}  included/excluded  {subtree}   {mask}

  where {name} is the identifier to be used for this view (i.e. what should
  appear in the access entry), and {subtree} is the portion of the MIB tree
  that this name refers to (in either numeric or named form).
    Note that the name of the view does not have to have anything to do
  with the MIB sub-identifier names - it's purely an identifying tag for
  use within the config file (though choosing a meaningful name is, as
  always, a very good idea).
  
    The {mask} field is used to control which elements of the OID subtree
  should be regarded as relevant when determining which view an OID is in.
  Normally, the whole of the OID should be included, so you'll need a mask
  with as many bits set as there are OID elements.
    Thus, in the example config file,  ".1" (i.e. the whole dod tree) has
  one element, so the mask has one bit set (counting from the most
  significant) - i.e. '80' (in hex).
  ".iso.org.dod.internet.mgmt.mib-2" has six elements, so six bits set ('fc').
  "system" is short for ".iso.org.dod.internet.mgmt.mib-2.system", which
  has seven elements, and so seven bits in its mask (hence 'fe')
    If there are more than eight elements, you specify the longer masks
  as single octet values, separated by dots (e.g. 'ff.c0' for 10 bits)
  The third field can be used to include or exclude particular portions
  of the MIB from the view, and different lines can use the same view name
  to build up a more complicated view, if that's what's needed.

    The three view fields in the access line are used to control which
  portions of the MIB tree a particular {group} can see (GET et al),
  alter (SET), or request NOTIFYs on.



    That's dealt with the "what" - now for the "who".
  This is the role of the "group" and "com2sec" entries.

  The "group" keyword gives general control, by mapping between a
  "security name" (and possibly a particular protocol version), and the
  internal name used in the access line.  This will really only come into
  play once the full features of SNMP v3 are available.

    At the moment, it's just an intermediate step between the "access" line
  and the "com2sec" line, which is the last bit of the jigsaw.
  The "com2sec" entry is used to determine a "security name" from the
  traditional community string, taking into account where the request has
  come from.  Thus the same community string can give access to  different
  portions of the tree, depending on where the request is sent from.

     For example, in the example config file, there are two com2sec lines
  with the community string "public" - one is valid from anywhere (with
  the security name "public") and one is only valid from the local network
  (using the security name "mynet").
     The group lines convert these security names into the groups "public"
  and "mygroup" respectively, and the access lines give these two groups
  the ability to GET values in the 'system' sub-tree (from anywhere) or
  the 'mib-2' sub-tree (from the local network).  Neither of these can
  SET any values though, (since the write-tree is "none" in both cases).
    Someone on the local machine, using the community string "private",
  has the security name "local" and the group name "local", and hence has
  full access (both GET and SET, as well as NOTIFY) to the whole of the
  MIB tree (or at least everything under .1, which covers most things!)

     Note that the three occurrences of "public", as community string,
  security name and group name, are three totally separate things.
  You can't use a community string in a security name field, or either
  of these as a group name (or vice versa), unless you set up suitable
  entries to map one name onto the other.


  And here concludes our tour of the view-based access control mechanism.
  Phew!



What ASN.1 parser is used?
-------------------------

  The parser used by both the agent and client programs is coded by hand.
  This parser has recently been re-vamped to allow control of which of 
  the available MIBs should be included, and to handle duplicate object
  subidentifiers.
    The source code can be found in the snmplib directory (in 'parse.c'),
  and the parser is usually bundled into the library 'libsnmp.a'

    Note that the parser attempts to be fairly forgiving of some common
  errors and incompatabilities in MIB files.  The UCD tools accepting a
  MIB file without complaint does not imply that the MIB is strictly
  correct.
    Certain MIBs (most notably those from Cisco) may need some amendments
  to allow them to be read correctly by the parser.  Contact the coders'
  list for advice.



How does the agent fetch the value of a variable from the system?
----------------------------------------------------------------

  Much of the information is extracted from kernel memory - usually
  by seeking to the appropriate location and reading the structures
  directly.
    Some systems provide cleaner interfaces to such kernel information
  (it would be hard to think of a less clean interface!), via ioctl()
  calls or similar system routines and these mechanisms are usually used
  in preference.



Why can't I see values in the UCDavis 'extensible' tree?
-------------------------------------------------------

  The extensible tree is designed to report things you ask it to report
  on.  If you don't declare anything in the snmpd.conf file for it to
  monitor, it will not report anything.  See the snmpd.conf manual page
  and the EXAMPLE.conf file for details on configuring the agent.

  As from version 3.4, the structure of the UCDavis MIB has been changed
  slightly, to bring it into conformance with MIB structure standards.
  This particularly affects the tables within this MIB.
    Make sure you have "make install"ed the MIB files that come with
  this release, and check any applications that may request these values.
  It's likely that the SNMP queries being sent will need amending.

  Also see the answer to the next few questions.


Why can't I see values in the UCDavis 'memory' tree?
---------------------------------------------------

  The memory mib is not supported on all operating systems.  More
  specifically, it is only supported on linux, hpux9, hpux10, bsdi2,
  bsdi3, freebsd2 and Solaris, and is not compiled in on any other
  architectures.  If you want to help port it to other systems, let us 
  know.



What does "klread:  bad address" mean?
-------------------------------------

  This means that the agent was unable to extract some of the
  necessary information from the kernel structures.  This is
  possibly due to:
	- either looking in the wrong place for kernel information
		(check the value of KERNEL_LOC)
	- an error in the implementation of part of the MIB tree
		for that architecture.  Try and identify which
		OID is generating the error, and contact the
		list 'ucd-snmp-coders@ucd-snmp.ucdavis.edu'



What does "nlist err:  wombat not found" (or similar) mean?
----------------------------------------------------------

  This means that the agent wasn't able to locate one of the
  kernel structures it was looking for.  This may or may not
  be important - some systems provide alternative mechanisms
  for obtaining the necessary information - Solaris, for example,
  can produce a whole slew of such messages, but still provide
  the correct information.
    This error only occurs if you have used the flag
  '--enable-debugging' as part of the initial configuration.
  Reconfigure the agent with '--disable-debugging' and these
  messages will disappear.



How about "Can't open /dev/kmem"?
--------------------------------

  This device is normally restricted to just being accessible by root
  (or possibly by a special group such as 'kmem' or 'sys').  The agent
  must be able to read this device to obtain the necessary information
  about the running system.
    Check that the agent was started by root, and is running with UID 0
  (or suitable GID if appropriate)

 

The agent is complaining about 'snmpd.conf'.  Where is this?
-----------------------------------------------------------

  It doesn't exist in the distribution as shipped.  You need to
  create it to reflect your local requirement.
    To get started, you can either just create this as an empty file,
  or try copying the EXAMPLE.conf file which will use some of the UCD
  extensions.  See the snmpd.conf(5) manual page for further details.



Sometimes I seem to get the wrong answers.  Why?
-----------------------------------------------

  Many of the variables in the basic MIB-2 tree require information
  that is not easily available in the common Unix kernels.  Prior to
  the v4 release, the agent returned hardwired 'null' values (in the
  absence of anything better).  As from release 4.0, the agent now
  returns a "noSuchName" error, which is more in keeping with the
  SNMP specification.
    The items affected are:

	interface.ifType		other(1)
	interface.ifSpeed		1
	interface.ifLastChange		0
	interface.ifInNUCastPkts	0
	interface.ifInDiscards		0
	interface.ifInUnknownProtos	0
	Interface.ifOutNUCastPkts	0
	interface.ifSpecific		Null OID

	ip.ipInUnknownProtos		0
	ip.ipInDiscards			0
	ip.ipOutRequests		0
	ip.ipOutDiscards		0
	ip.ipFragOKs			0
	ip.ipFragFails			0
	ip.ipFragCreates		0
	ip.ipRouteDiscards		0
	ipAddrEntry.ipAdEntReasmMaxSize	-1
	ipRouteEntry.ipRouteAge		0

	tcp.tcpMaxConn			-1
	tcp.tcpOutRsts			0

	udp.udpInDatagrams		0
	udp.udpNoPorts			0
	udp.udpOutDatagrams		0


  The following variables have 'likely guess' values, that are not
  necessarily strictly accurate.

	interface.ifInOctets		guess based on # of packets
	interface.ifInUCastPkts		includes non-unicast packets
	interface.ifOutOctets		guess based on # of packets
	interface.ifOutUCastPkts	includes non-unicast packets

	ip.ipInDelivers			Doesn't handle fragments properly
	ip.ipReasmOKs			Assumes fragments are complete datagrams
	ipRouteEntry.ipRouteProto	local(2) or icmp(4)

	tcp.tcpRtoAlgorithm		vanJ(4)   (probably correct!)


  The following variables are simply not implemented according to specification

	tcp.tcpAttemptFails		} actually counting
	tcp.tcpEstabResets		} something different
	tcp.tcpOutResets		}


  Some systems may return the correct information for these values.
  Systems that are believed to have corrected some of these are as follows:

	*  FreeBSD & BSDi provide correct interface statistics
	*  Solaris, Linux & HP-UX provide correct statistics throughout
		(though Solaris may need a kernel patch to support interface
		 octet counts, and Linux requires kernel 2.2 or better).

  

Why have some variables disappeared from the agent?
--------------------------------------------------

    This is related to the previous question.  The information necessary to
  provide correct values for some variables is not available on some systems,
  In previous releases, the agent attempted to guess sensibly, or provided
  a "null" answer, which was contrary to SNMP specifications.
    The agent now (correctly) treats this as an unavailable variable, and
  returns an error.

    If you *really* insist on the agent returning wrong answers, then you can
  return to the previous behaviour by using the configure flag "--with-dummy-values"



The system uptime (sysUpTime) returned is wrong!
-----------------------------------------------

  Oh no it's not.
  The defined meaning of 'sysUpTime' is
	"the time ... since the *network management*
	 portion of the system was re-initialized."

  In other words, when the snmp agent was started, not when the
  system itself last booted.  This latter information is available
  in the Host Resources MIB as "host.hrSystem.hrSystemUpTime"
  Note that even if the full Host Resources is not supported on
  your system, it's worth trying configuring using

		'--with-mib-modules=host/hr_system'

  and recompiling.  This particular group is reasonably likely to
  work, even if some of the other more system-specific groups don't.
	(see the next question)



The Host Resources information is wrong (and/or doesn't even compile)!
---------------------------------------------------------------------

  Very likely.

  This is still a very new implementation, and has only really been
  tried on a limited number of systems.  While every attempt is made
  to provide information in as general way as possible, the Host
  Resources is extremely system-specific, by its very nature.

     The current list of systems that have a relatively complete
  implementation of this MIB is:

	- HP-UX 9 & 10
	- Solaris 2.5 and above
	- RedHat Linux 5 and above

  Though the hrDevice table in particular is somewhat sparse, even on these.
  If your system is not listed here, and you would like to help implement
  it, contact the coders list, and make a friend for life!



What is the Official Slogan of the ucd-snmp-coders list?
-------------------------------------------------------

  "The current implementation is non-obvious and may need to be improved."
	(with thanks to Rohit Dube)




PERL
====

How do I install the Perl SNMP module?
-------------------------------------

  Assuming you have a reasonably new (and properly configured) perl system,
  this should be simply:

	perl Makefile.PL
	    (press RETURN when prompted for host and community)
	make
	make test
	make install  (probably as root)



Compiling this fails with "`MAX_NAME_LEN' undeclared"?
-----------------------------------------------------

  This name is no longer used (from release 3.6 onwards), due to clashes with
  system header files on some systems.  There should be a new version of the Perl
  SNMP module out soon (probably 1.9) that handles this.
    In the meantime, changing the file SNMP.xs (in the perl module) to replace
  each occurrence of 'MAX_NAME_LEN' with 'MAX_OID_LEN' will work.



I'm trying to use mib2c (or tkmib) and it can't locate SNMP.pm?
------------------------------------------------------------

  That's probably because the SNMP perl module hasn't been installed.
  It's not part of the standard distribution, nor is it installed by
  default in RedHat linux (for example).
    You'll need to get it from CPAN, and install it yourself
  (see the first question in this section).



I'm trying to use tkmib and it can't locate Tk.pm?
------------------------------------------------------------

  Tk.pm is another Perl package that needs to be installed before tkmib will run.
  It's also available on Perl CPAN.  We suggest using version "Tk800.011" or later.



GENERAL PROBLEMS
================

Why aren't my mib files read in any more?
-----------------------------------------

  There are a number of possible reasons for this.
  In summary:	a particular MIB file isn't being read in
		none of the MIB files are found
		there's an error in the MIB file

  To expand on these in turn:

  *  As from version 3.2, the parser has been re-written.  One effect
  of this is that only a specified set of MIB modules are read in by
  the tools by default.  This list can be set in a number of ways:

    The tools have a default list compiled in, which can be set
  using the configure option
		--with-mibs="list"
  and recompiling the tools.

    The environmental variable 'MIBS' will be taken as a list of
  module names (separated by colons) to be read in, instead of (or as
  well as) the default list.  Note that any modules these rely on will
  be read in automatically, without needing to be listed explicitly.
    Note also that this refers to the name of the MIB (i.e. the name
  before the token 'DEFINITIONS'), which is not necessarily the same
  as the name of the file containing it.
  

    The environment variable 'MIBFILES' will be taken as a list of
  filenames, containing MIB modules to be read in (instead of, or in
  addition to those included by 'MIBS' and/or the default list).
  Again, any modules these rely on will also be loaded in automatically.
    The names listed in this variable can be anywhere in the filesystem,
  though any implicitly loaded modules must be present in the standard
  location(s). 

    Finally, if the environmental variable 'MIBS' has the special
  value "ALL", then the tools will load in every module present in
  the module directory (or directories).

  The command line options '-m' and '-M' can also be used to override
  these variables.  This is described in the 'snmpcmd(1)' man page.


  * The location where the tools look for MIB module files is compiled
  into the tools. This can also be set using the environmental
  variable 'MIBDIRS', being a (colon-seperated) list of directories
  containing MIB files. 

  Note that from version 3.3 onwards, the default location has changed
  (from /usr/local/lib/snmp/mibs to /usr/local/share/snmp/mibs).
  This is in line with current standards regarding file system structure.


  * As from version 3.4, the parser is somewhat more strict about the
  syntax of MIB files.  This may result in it rejecting previously
  acceptable (though erroneous) MIB files.
     See the next-but-two question for more help on this.

  See the 'mib_api(3)' man page for more details of how MIBs are parsed.



I'm getting answers, but they're all numbers. Why?
-------------------------------------------------

  This is actually the same as the previous question.  Because the tools
  no longer read in every MIB module they can find, it is quite possible
  for results from an agent to refer to modules that have not been loaded
  (particularly with GETNEXT requests, or when walking a tree).
     The tools will report the answer quite correctly, but won't translate
  identifiers and enumerations into readable strings.  To fix this, use
  the environmental variables MIBS or MIBFILES (or the '-m' and '-M' flags)
  to read in the relevant module files.
    This does assume you have these files installed properly.  There's not
  a great deal we can do if you haven't.   Note that the default location
  for these files has changed recently (see the previous question).



The parser doesn't handle comments properly. Why not?
------------------------------------------------------------

  The most likely reason is that the line in question contains two
  (or more) sequences of pairs of dashes.  This is often used to try
  and "comment out" an unwanted line that already contains a comment:

	--   broken ::= { myMIB 1 }   -- This isn't working yet

  The assumption here is that a comment continues to the end of the line.
  Unfortunately, this assumption is not correct.
    A comment will continue either to the end of the line, or the next
  occurance of a pair of dashes.  Thus in this case, the definition of
  "broken" is commented out (as intended) but the following text is
  treated as part of the MIB, and will generate an error.

    A similar effect can be obtained when a line of dashes has been used
  to try and mark separate parts of a MIB file.

    Most of the applications have a command-line option (-Pc) which will
  work around this problem by treating the whole line as a comment.  But
  this is not strictly legal, and the offending MIB file should really be
  corrected.



How can I get more information about these MIB file problems?
------------------------------------------------------------

  The command 'snmptranslate' is used to translate between numeric
  and symbolic forms of OIDs.  It uses the same routines as the
  'active' commands, but does not rely on communicating successfully
  with a network management agent.  As such, it is a useful tool
  for identifying problems with reading in MIB files.

    In particular, the following options may be useful in
  identifying problems:
	-Pw  warns about conflicting symbols
	-PW  prints more verbose warnings about other problems as well
		(in both cases, ignore the 'xmalloc' reports)
	-p   prints a list of the entries that have been read in
		(including the MIBs they belong to)
	-T   provides sub-options for various views of these entries

  There are other '-P' options to control various aspects of MIB parsing.
  See the 'snmptranslate(1)' and 'snmpcmd(1)' man pages for more details.



What's this about "too many imported symbols"?
---------------------------------------------

  Any MIB file starts with an (optional) list of identifiers that
  it "imports" from other files.  The parser implements this using
  a fixed size buffer to hold the import information.
    There are two circumstances in which this can result in the
  error message shown above.

    Firstly, if the MIB file refers to an unususally large number
  of external identifiers.  Handling this case requires a (trivial)
  patch to the parsing code.  Contact the coders list for advice.
     (This is extremely rare - the only example that
      we've come across is the Cabletron Trap MIB).

    Much more common is a syntax error in the IMPORTS clause of the
  MIB file in question.  In particular, check that this ends in a
  semicolon, before going on to the main definition section.
  


How do I compile with 'gcc' instead of 'cc'?
-------------------------------------------

  Set the environmental variable 'CC' to have the value 'gcc' before
  running the configure script.



But gcc doesn't compile it successfully on my new Solaris system. Why not?
-------------------------------------------------------------------------

  Whenever you upgrade the operating system under Solaris, you need to
  reinstall gcc, and run the 'fixincludes' script.  (This is probably
  a sensible step to take when you upgrade any operating system).
    Under Solaris 2.6, there is also a bug in the gcc 'fixinc.sv4' script.
  This needs an additional line as follows:

*** fixinc.svr4.cln     Thu Jun 15 22:03:29 1995
--- fixinc.svr4 Tue Nov 25 09:47:57 1997
***************
*** 191,191 ****
--- 191,192 ----
          s/__STDC__ - 0 == 0/!defined (__STRICT_ANSI__)/g
+         s/__STDC__ - 0 == 1/defined (__STRICT_ANSI__)/g