Frequently Asked Questions (FAQ) for the UCD/Net SNMP package
      =============================================================
		       FAQ Author: Dave Shield
		        ucd-snmp Version: 4.2.3
		ucd-snmp Project Author: Wes Hardaker
		Email: net-snmp-coders@lists.sourceforge.net

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

 TABLE OF CONTENTS
 GENERAL
   What is it?
   Where can I get it?
   What documentation is available?
   Are there binaries available?
   What's the difference between UCD-SNMP and Net-SNMP?
   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 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?
   Requests always seem to timeout, and don't give me anything back.  Why?
   I can see the system group, but nothing else.  Why?
   Requesting an object fails with "Unknown Object Identifier"  Why?
   Why do I get "noSuchName" when asking for "sysUpTime" (or similar)?
   Why do I sometimes get "End of MIB" when walking a tree, and sometimes not?
   I cannot set any variables in the MIB.
   Variables seem to disappear when I try to set them.  Why?
   I get an error when trying to set a negative value - why?
   How do I send traps and notifications?
   How do I handle traps and notifications?
   How do I use SNMPv3?
   How big can an SNMP request (or reply) be?
   How can I monitor my systems (disk, memory, etc)?
   Applications complain about entries in your example 'snmp.conf' file.  Why?
   OK, what should I put in snmp.conf?
 MIBS
   Where can I find a MIB compiler?
   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?
   Why aren't my mib files being read in?
   I'm getting answers, but they're all numbers. Why?
   The parser doesn't handle comments properly. Why not?
   How do I replace MIB values with new ones ?
   How can I get more information about these MIB file problems?
   What's this about "too many imported symbols"?
 PERL
   Where can I get the perl SNMP package?
   How do I install the Perl SNMP module?
   But compiling this fails! Why?
   Compiling the perl module works OK, but 'make test' fails. Why?
   I'm trying to use mib2c (or tkmib) and it can't locate SNMP.pm?
   I'm trying to use mib2c (or tkmib) and it can't load SNMP.so?
   I'm trying to use tkmib and it can't locate Tk.pm?
 AGENT
   What MIBs are supported?
   What protocols are supported?
   How do I configure the agent?
   How do I add a MIB to the agent?
   What's the difference between 'exec', 'sh' and 'pass'?
   What's the difference between AgentX, SMUX and proxied SNMP?
   Which should I use?
   How can I combine two copies of the 'mib2' tree from separate subagents?
   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?
   How can I listen on just one particular interface?
   How do I configure access control?
   I don't understand the new access control stuff - what does it mean?
   How do I configure SNMPv3 users?
   The 'createUser' line disappears when I start the agent.  Why?
   What's the difference between /var/ucd-snmp and /usr/share/snmp?
   My new agent is ignoring the old snmpd.conf file. Why?
   Why am I getting "Connection refused"?
   I'm getting errors about "bad security model" - why?
   I'm getting errors about "bad prefix match parameter" - why?
   Why can't I see values in the UCDavis 'extensible' or 'disk' trees?
   Why can't I see values in the UCDavis 'memory' or 'vmstat' tree?
   What do the CPU statistics mean - is this the load average?
   What about multi-processor systems?
   The speed/type of my network interfaces is wrong - how can I fix it?
   The interface statistics for my subinterfaces are all zero - why?
   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?
   The system uptime (sysUpTime) returned is wrong!
   The Host Resources information is wrong (and/or doesn't even compile)!
 CODING
   How do I compile with 'cc' instead of 'gcc'?
   But gcc doesn't compile it successfully on my new Solaris system. Why not?
   How do I write C code to integrate with the agent?
   How does the agent fetch the value of a variable from the system?
   I've created a new module with 'mib2c' but it doesn't work.  Why not?
   Where should I put the files produced by 'mib2c'?
   Mib2c only handles a single table in my MIB. How can I fix this?
   Mib2c complains about a missing "mib reference" - what does this mean?
   How can I get the agent to generate a trap (or inform)?
   I'm getting an error "autoheader: not found" - what's wrong?
   Why is the project workspace empty under Visual C++?
   Why are packets requesting the same information larger with UC-Davis SNMP ?
   What ASN.1 parser is used?
   What is the Official Slogan of the ucd-snmp-coders list?


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?
------------------

  Download:
    - http://www.net-snmp.org/download/
    - ftp://ftp.net-snmp.org/pub/sourceforge/net-snmp/ucd-snmp.tar.gz
  Web page:
    - http://www.net-snmp.org/
  Sourceforge Project page:
    - http://www.net-snmp.org/project/
  Mirrors:
    - US:        ftp://ftp.freesnmp.com/mirrors/net-snmp/
    - Bulgaria:  http://rtfm.uni-svishtov.bg/net-snmp/
    - Japan:     ftp://ftp.ayamura.org/pub/net-snmp/
    - Germany:   ftp://ftp.mpg.goe.ni.schule.de/pub/internet/net-snmp/

  Mirrors of the older ucd-snmp.ucdavis.edu site:
    - ftp://ucd-snmp.ucdavis.edu/ucd-snmp.tar.gz
    - ftp://sunsite.cnlab-switch.ch:/mirror/ucd-snmp/ucd-snmp.tar.gz
    - ftp://ftp.win.ne.jp/pub/network/snmp/ucd-snmp/ucd-snmp.tar.gz
    - ftp://ftp.chg.ru/pub/networking/management/snmp/ucd-snmp/ucd-snmp.tar.gz
    - ftp://mirror.aarnet.edu.au/pub/ucd-snmp/ucd-snmp.tar.gz
    - ftp://archive.logicnet.ro/mirrors/ucd-snmp.ucdavis.edu/


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
	A Tutorial at http://www.net-snmp.org/tutorial/

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

        	http://www.net-snmp.org/



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

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



What's the difference between UCD-SNMP and Net-SNMP?
---------------------------------------------------

  Not a great deal, really.
  Although the project originally started at UC Davis (hence the name),
  and it has always been based there, most of the contributors have had
  little or no connection with this institution.

    The recent move to SourceForge is intended to provide a more flexible
  environment for the project, and to distribute the administrative
  workload more evenly.  The change of name simply reflects this move,
  which was the last remaining link with UC Davis.

    The 4.2 line is the last release line that will use the ucd-snmp name.
  4.2.1 and any subsequent ucd-snmp releases will be bug-fixes only.
  All further developments will be released under the net-snmp name.
  
    At some point, we are planning to review and rework the underlying
  code base, to improve the readability and maintainability of the
  package.  This will probably result in some changes to the API,
  though we will attempt to retain some form of backwards
  compatability as far as possible, and clearly mark anything that has
  changed.



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 operating systems:

	* HP-UX (10.20 to 9.01)
	* Ultrix (4.5 to 4.2)
	* Solaris (2.8 to 2.3) and SunOS (4.1.4 to 4.1.2)
	* OSF (4.0, 3.2)
	* NetBSD (1.5alpha to 1.0)
	* FreeBSD (4.1 to 2.2)
	* BSDi (4.0.1 to 2.1)
	* Linux (kernels 2.2 to 1.3)
        * AIX (4.1.5, 3.2.5)
        * OpenBSD (2.8, 2.6)
        * Irix (6.5 to 5.1)

  See the next question but one for the status of Windows support.

  Certain systems (e.g. HP-UX 11, Irix?) fail to compile particular
  portions of the agent.  These can usually be persuaded to compile
  (at the loss of some functionality) by omitting the modules affected.
  See the next question for more details.

  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
  that we think we've fixed!)



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

    Try "configure --enable-mini-agent --with-defaults".
  If configure fails with "invalid configuration" messages,
  contact the coders list for advice.  Otherwise, see if this
  minimal agent compiles successfully.

    If so, try adding the missing mibgroups (either one at a
  time or en masse, depending how adventurous you're feeling),
  using the configure option '--with-mib-module'.
    If a particular module fails to compile, omit it using
  '--with-out-mib-module', and try again.

  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 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!).
  Note that the UCD pass-through extensions do not work under Windows.

  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

  	net-snmp-announce@lists.sourceforge.net

  To be added to (or removed from) this list, visit
  http://www.net-snmp.org/lists/net-snmp-announce/.  Or you can send a
  message to the address
  'net-snmp-announce-request@lists.sourceforge.net' 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://www.net-snmp.org/patches/



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

  There is a general purpose discussion list

  	net-snmp-users@lists.sourceforge.net

  To be added to (or removed from) this list, visit
  http://www.net-snmp.org/lists/net-snmp-users.  Or you can send a
  message to the address 'net-snmp-users-request@lists.sourceforge.net'
  with a subject line of 'subscribe' (or 'unsubscribe' as appropriate).

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

  There is also an net-snmp IRC channel set up on the openprojects.net
  IRC chat servers (see http://www.openprojects.net/ for getting
  started with irc).  Multiple core developers hang out there on a
  regular basis.


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

  All bug reports should be submitted to the bug database through the
  interface found at http://www.net-snmp.org/bugs/.  Be
  sure to include 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.

    All patches should be submitted to the patch manager at
  http://www.net-snmp.org/patches/.  If possible, submit a
  bug report describing the patch as well (referencing it by its patch
  number) since patch manager doesn't contain a decent description
  field.

    Questions about using the package should be directed at the
  net-snmp-users@lists.sourceforge.net mailing list.  Be advised that
  the people answering these kinds of questions are doing so out of
  the goodness of their hearts, as this is an otherwise unsupported
  package.  Please also be advised that posting notes using a html
  based mailer only annoys people, and posting notes more than once
  ("no one answered this so I'm posting it again") only annoys them
  even more.  As long as you stay away from those two no-no's, we're a
  rather friendly bunch.

    There is also an net-snmp IRC channel set up on the openprojects.net
  IRC chat servers (see http://www.openprojects.net/ for getting
  started with irc).  Multiple core developers hang out there on a
  regular basis.

    We can't promise to be able to solve the problem, but we'll
  certainly try and help.  Please *don't* mail both the coders
  and users lists - choose one or the other.  Most of the core
  contributors read both lists, and will respond as quickly and
  helpfully as we can.  Duplicated messages simply increase the
  load on these (already busy) lists, and are likely to annoy,
  rather than encourage a sympathetic response.

    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 asking for help with a problem, please enclose the exact
  command you tried, and the output it generated.  Comments like "I did
  what it said in the man page", or "I've tried everything" aren't very
  helpful.  Exact messages, please!

   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
  this version of the software is no longer being actively supported.



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 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.

  The applications and the agent have not been designed for threaded use.





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?
-------------------------------

  Firstly,

	cp MY-MIB.txt /usr/share/snmp/mibs

          or

        mkdir $HOME/.snmp
        mkdir $HOME/.snmp/mibs
	cp MY-MIB.txt $HOME/.snmp/mibs

  And then,

	export MIBS=+MY-MIB

          or alternatively:

        echo "mibs +MY-MIB" >> $HOME/.snmp/snmp.conf

  Note that you need *both* steps.
  The first command copies the file defining the new MIB to a
  expected location for MIB files.  This defaults to
  /usr/share/snmp/mibs (or PREFIX/share/snmp/mibs if the the
  suite was installed into a different base location).  Some
  ready-packaged distributions (such as Linux RPM packages) may look
  for MIB files in a different location, such as /etc/snmp/mibs - put
  the new file in this dirctory instead.  This makes it available for
  everyone on the system.
  The tools will also look for mibs in your personal $HOME/.snmp/mibs
  directory, but this will only work for you.

  The second command tells the tools to load in this new MIB file as well
  as the default set.   Note that the tools do *not* load every MIB found
  in the directory - this is to avoid slowing them down excessively when
  there is a large collection of MIB files.  If you do want the tools to
  load all the MIB files, set the environmental variable MIBS to the special
  value "ALL".

     Note that the value for this variable is the name of the MIB module,
  *not* the name of the MIB file.   These are typically the same (apart
  from the .txt suffix), but if in doubt, check the contents of the file.
  The value to use is the token immediately before the word DEFINITIONS
  at the start of the file.  Of course, if you load 'ALL' mibs, then this
  distinction is irrelevant.

    Most of the tools (apart from 'snmptable') will work quite happily
  without any MIB files at all, as long as you are prepared to work with
  numeric OIDs throughout.  The MIB files are only used for translating
  between numeric and textual forms for queries and responses.
    The same holds true for the agent - see the AGENT section for details.



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

  A simply call to 'snmpwalk' (without specifying what to retrieve) will
  display the contents of the 'mib-2' subtree.  It will not attempt to
  traverse any 'private.enterprise' subtrees.  This includes the UCD
  UCD-specific objects (including any local extensions).

    To walk the whole tree, specify a starting point of '.iso'
  To walk a specific enterprise subtree, specify the root of this as
  the starting point - e.g:

	snmpwalk localhost public ucdavis
 
  Or, of course, you can walk a selected portion of an enterprise subtree
  by specifying the appropraite starting point - e.g:

	snmpwalk localhost public ucdavis.version
  
  If you still can't see any information, keep reading.  The next few
  questions will probably help you.



Requests always seem to timeout, and don't give me anything back.  Why?
----------------------------------------------------------------------

  There are a number of possible causes of this.
  Firstly, are you sure that the machine you are querying is actually up?
  Check that it responds to a 'ping' request and that that there is an
  SNMP process running on it.

  Secondly, it may simply be taking a long time to process the request.
  Try running the request with a long timeout value (e.g. '-t 120')

  If the system responds to ping, but not to a simple SNMP request
  (regardless of the timeout), then the problem may be due to the access
  configuration of the agent.  If the community string you have specified
  is not recognised, then the agent will simply not respond.
    See the next question, or the question on access control in the AGENT
  section for more details.

    Another possibility is TCP wrapper settings.  See the question

	Why am I getting "Connection refused"?

   for more details of this.   (Don't worry that the symptoms aren't
   correct - it may still be relevant)



I can see the system group, but nothing else.  Why?
--------------------------------------------------

  This is probably the same as the previous question - a problem with
  the access configuration of the agent.   The easiest way to test this
  is to try a GETNEXT request, that ought to return the entry of interest.
  e.g.
	snmpgetnext localhost public ucdavis.version.versionTag
  instead of
	snmpget     localhost public ucdavis.version.versionTag.0

  If the agent responds with "end of MIB" or a different object, then
  either the agent doesn't implement that particular object at all, or
  the access control won't allow you access to it.

    This is frequently experienced with Linux systems, which often tend to
  come with the UCD agent configured to only allow access to the system group.

  If the agent being queried is the UCD agent, then see the entry on access
  control in the AGENT section for how to deal with this.
    If it is a different agent, you'll need to see the documentation that
  came with it.  (But of course, a non-UCD agent is unlikely to implement
  the 'ucdavis' sub-tree, so the examples above won't work anyway!)

  As a quick fix, you might create a new snmpd.conf configuration file
  that gives you the access control you need.  Run snmpconf -g
  basic_setup and follow its instructions.  Alternatively, add a
  line
	rocommunity public
                           to your snmpd.conf file, and restart.
  See the FAQ entries on access control for more details.



Requesting an object fails with "Unknown Object Identifier"  Why?
----------------------------------------------------------------

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

    Firstly, make sure that you're asking for the object by the right name.
  Object descriptors are case-sensitive, so asking for 'sysuptime' will
  not be recognised, but 'sysUpTime' will.

    Secondly, the object may be defined in a MIB that hasn't been loaded.
  Try loading in all the MIB files:

	snmpget -m ALL localhost public sysUpTime.0

  (though if snmpwalk translates it OK, that's less likely to be the cause).

    Thirdly, earlier versions of the UCD software expected "full" paths
  for object names, either based at the root of the whole MIB tree
  (".iso.org.dod.internet.mgmt.mib-2.system.sysUpTime") or the 'mib-2'
  subtree ("system.sysUpTime").  Try:
  
	snmpget myhost public system.sysUpTime.0

  These earler versions of the tools may take a command-line option '-R'
  or '-IR' (depending on vintage) to invoke this "random-access" mode.
  Note that snmptranslate still requires "random-access" to be specified
  explicitly - all other command tools now use this mode by defaults.

  All versions of the tools accept the syntax

	snmpget myhost public RFC1213-MIB:sysUpTime.0

  to denote a particular object in a specific MIB module.  Note that this
  uses the name of the *module*, not the name of the file.  See the second
  question in this section for the distinction.



Why do I get "noSuchName" when asking for "sysUpTime" (or similar)?
------------------------------------------------------------------

  There are a number of possible causes of this (scattered throughout
  this FAQ, so keep reading!).   But one of the most likely snares for
  the unwary is forgetting the instance subidentifier for 'non-table'
  objects.  If you walk the 'system' tree, you'll notice that all the
  results (apart from the sysORTable), have a '.0' at the end of the OID.
  This is the "instance sub-identifier" - which *must* be included for
  a GET request.
     Compare the following:

	$ snmpget localhost public sysUpTime
	Error in packet
	Reason: (noSuchName) There is no such variable name in this MIB.
	This name doesn't exist: system.sysUpTime
	$ snmpget localhost public sysUpTime.0
	system.sysUpTime.0 = Timeticks: (69189271) 8 days, 0:11:32.71

  This is a little less obscure when using SNMPv2c or v3 requests:

	$ snmpget -v 2c localhost public sysUpTime
	system.sysUpTime = No Such Instance currently exists



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 and what you're asking for.

  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 object X happens to be the last entry in a sub-tree, the agent will
  provide the next object 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 object X happens to be the last entry supported by the agent,
  it doesn't have another object 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 cannot set any variables in the MIB.
-------------------------------------

  There are three possible reasons for this:

  The majority of MIB objects are defined as "read-only" and inherently
  cannot be changed via SET requests.

  Of those that can in principle be changed, not all have been implemented
  as such in this agent.

  Even if SET support has been implemented, the agent may not be configured
  to allow write access to this object.

  The example configuration file shipped with the basic distribution only
  allows write access for the local host itself (and a suitable community
  name must be configured first).
    Ready-installed distributions (such as those shipped with Linux) tend
  to be configured with read-only access to part of the mib tree (typically
  just the system group) and no write access at all.

  To change this, you will need to set up the agent's access control
  configuration.  See the AGENT section for more details.

    Note that neither the community string "public" nor "private" can be
  used to set veriables in a typical default configuration.



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, particularly when using SNMPv1.  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

  Trying the same request using SNMPv2 or above is somewhat more informative:

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

  The SNMPv1 error 'noSuchName' actually means:

	"You can't do that to this variable"

  This might 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).
    Similarly, the SNMPv2 error 'notWritable' means "not writeable in
  this particular case" rather than "not writeable under any circumstances".

  If you are sure that the object is writeable (and has been implemented
  as such), then you probably need to look at the agent access control.
  See the AGENT section for more details.



I get an error when trying to set a negative value - why?
--------------------------------------------------------

    This is a different problem.  What's happening here is that the
  routine that parses the arguments to the 'snmpset' command is seeing
  the '-' of the new value, and treating it as a command-line option.
  This normally generates an error (since digits probably aren't valid
  command line option).

    The easiest way to solve this is include the "end-of-option"
  indicator '--' in the command line, somewhere before the new value
  (but after all of the options, obviously).  For example:

	snmpset -v 2c localhost public -- versionRestartAgent.0 i -1

  (This will also fail, since -1 isn't an acceptable value for this
  object, but it will be rejected by the agent, rather than confusing
  the snmpset command!)



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

    Traps and notifications can be sent using the command 'snmptrap'.
  The following examples generate the generic trap 'coldStart' and a
  (dummy) enterprise specific trap '99' respectively:

	snmptrap -v 1 -c public localhost "" "" 0 0  ""
	snmptrap -v 1 -c public localhost "" "" 6 99 ""
  
  The empty parameters "" will use suitable defaults for the relevant 
  values (enterprise OID, address of sender and current sysuptime).

    An SNMPv2 or SNMPv3 notification (either trap or inform) takes
  the OID of the trap to send:

	snmptrap -v 2c -c public localhost "" UCD-SNMP-MIB::ucdStart
	snmptrap -v 2c -c public localhost "" .1.3.6.1.4.1.2021.251.1

  (These two are equivalent ways of specifying the same trap).

  Any of these commands can be followed by one or more varbinds,
  using the same (OID/type/value) syntax as for 'snmpset':

	snmptrap -v 2c -c public localhost "" ucdStart sysContact.0 s "Dave"

  Generating traps from within the agent is covered in the AGENT and
  CODING sections.

  You should also read the snmptrap tutorial at
	http://www.net-snmp.org/tutorial/commands/snmptrap.html
  which will help you understand everything you need to know about traps.



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

    Handling received traps is done using the tool 'snmptrapd'.
  This can log these traps via the syslog mechanism:

	snmptrapd -s -l7	(log to 'LOCAL7')

  printed to standard output

	snmptrapd -f -P

  or pass them to an external command.  This last approach uses
  a 'traphandle' directive in the configuration file 'snmptrapd.conf'.
  A typical file might look something like:

	traphandle .1.3.6.1.6.3.1.5.1       page_me up
	traphandle .1.3.6.1.4.1.2021.251.1  page_me up
	traphandle .1.3.6.1.4.1.2021.251.2  page_me down
	traphandle default                  log_it

  where 'page_me' and 'log_it' are the command to be run.  (You probably
  need to specify full pathnames, to ensure that the commands will be
  found.  They're just short here for readability).

  Note that the first entry uses the OID corresponding to the SNMPv1
  'coldStart' trap.  See the co-existence RFC (RFC 2576) for details
  of mapping SNMPv1 traps to SNMPv2 OIDs.

  There's a tutorial with more details on the web site at
	http://www.net-snmp.org/tutorial/commands/snmptrap.html
  


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

    The simplest form of SNMPv3 request (unauthenticated, unencrypted)
  would be something like:

	snmpget -v 3 -l noAuthNoPriv localhost sysUpTime.0


    An authenticated request would specify a username and pass phrase:

	snmpget -v 3 -l authNoPriv -u dave -A "Open the Door"
				localhost sysUpTime.0

    A fully secure request would also specify the privacy pass phrase:

	snmpget -v 3 -l authPriv -u dave -A "Open the Door"
			-X "Bet you can't see me"  localhost sysUpTime.0


  In practise, most of these would probably be set via configuration
  directives in a personal $HOME/.snmp/snmp.conf file (note, *not* the
  agent's snmpd.conf file).  The equivalent settings for the third
  example would be:

	defSecurityName		dave
	defSecurityLevel	authPriv
	defAuthPassphrase	"Open the Door"
	defPrivPassphrase	"Bet you can't see me"


  For how to configure the agent to respond to SNMPv3 requests, see
  the AGENT section.
 


How big can an SNMP request (or reply) be?
-----------------------------------------

    The protocol definition specifies a "minimum maximum" packet size
  (484 bytes for UDP), which all systems must support, but does not
  attempt to define an upper bound for this maximum size.  This is left
  to each individual implementation.

    The UCD software uses a fixed size buffer of 1472 bytes to hold the
  encoded packet, so all requests and responses must fit within this.
  Unfortunately, it's not possible to predict how many varbinds this
  corresponds to, since it depends on the type and actual values being
  sent, as well as the corresponding OIDs.

    As a rule of thumb, sending 400 integer-valued varbinds seems to
  work OK, while 300 string-valued varbinds triggers an overrun.



How can I monitor my systems (disk, memory, etc)?
------------------------------------------------

    In general, the UCD suite consists of relatively low-level tools,
  and there is nothing included that is designed for high-level,
  long-term monitoring of trends in network traffic, disk or memory
  usage, etc.

    There are a number of packages available that are designed for this
  purpose.  Two of the most widely used are MRTG (http://www.mrtg.org/)
  and Cricket (http://cricket.sourceforge.net/).  There are details of
  how to set up Cricket to monitor some of the UCD extensions at
  http://www.afn.org/~jam/software/cricket/

     We have also set up a page that describes in detail how MRTG
  can be set up to monitor disk, memory and cpu activity at
  http://www.net-snmp.org/tutorial/mrtg/index.html

    The net-snmp package contains a web based manager itself that
  runs on top of a mysql database, but it is extremely beta in
  nature.  See the manager/README file for details.



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.
    Note that there is no example snmp.conf shipped with the standard
  distribution.



OK, what should I put in snmp.conf?
----------------------------------

    This is used to set common configuration values for most of the
  applications, to avoid having to specify them every time.  Examples
  include the SNMPv3 settings mentioned above, defaults for which MIBs
  to load and where from, and the default SNMP version, port and
  (if appropriate) the community string to use.

    Some of these (such as the MIB file location), might belong in a
  shared snmp.conf file (typically /etc/snmp/snmp.conf) to
  apply to all users of the system.  Others (particularly the SNMPv3
  security settings), are more likely to refer to a particular user, and
  should go in a personal snmp.conf file (typically $HOME/.snmp/snmp.conf).

    Note that the UCD package does not come with an example snmp.conf file.
  See 'snmpget -H' and/or the snmp.conf(5) man page for more details.

    You can also use the "snmpconf" command to help you generate your
  snmp.conf configuration file (just run it and answer its questions).



PERL
====

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

  Joe Marzot's excellent perl SNMP module, which requires the ucd-snmp
  library, is now included in the ucd-snmp source release.  It's
  located in the perl/SNMP subdirectory of the ucd-snmp source tree.

  It can also 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.



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

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

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



But compiling this fails! Why?
-----------------------------

  The perl module tends to delve quite deeply into the internals of the
  main UCD snmp library, and so is quite sensitive to changes within the
  library.  It's important to use the correct version of the module, that
  corresponds to the version of the library you have installed.  If you're
  working with the main UCD distribution, the appropriate version of the
  perl module is shipped as part of this, but you *must* have
  run "make install" on the main UCD distribution *first*.

  If you're working with a ready-installed version of the library, make
  sure you obtain a compatible version of the perl module.



Compiling the perl module works OK, but 'make test' fails. Why?
--------------------------------------------------------------

  That's difficult to answer in general.
  Some of the perl tests are rather picky, so this may simply be
  some minor inconsistency between your precise setup, and the
  expectations of the test environment.

    Check that you are working with the perl distribution that matches
  the SNMP libraries (use the 'perl/SNMP' in preference to CPAN), and
  that you have installed the main libraries successfully (uninstall
  any old versions if you're having trouble).

    If all this looks OK, and if most of the tests pass, then it's
  probably safe to run 'make install' anyway.   Probably.



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 perl distribution, nor is it installed
  by default in RedHat linux (for example).
    You'll need to install it.  See the previous two questions.



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

    This is probably the same problem.  Either the SNMP module
  hasn't been installed, or it's the wrong version.  See the
  previous two questions.



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.  It can be installed by issuing the command:

		perl -MCPAN -e shell ; "install Tk"



MIBS
====

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.  The command 'mib2c'
  is an example of such a tool for the UCD agent.  
  See the CODING section for more information.



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).



Why aren't my mib files being read in?
-------------------------------------

    The UCD library only loads a subset of MIB files by default.  This
  list is set at when the suite is first configured and compiled, and
  basically corresponds to the list of modules that the agent supports.
  (This is a simplification, but is a reasonable first approximation).

    You can override this by using the command-line option '-m', the
  environmental variable 'MIBS' or the snmp.conf directive 'mibs'.
  Each of these take a (colon-separated) list of MIB module names
  to load.   Starting the list with a '+' character will add them to
  the default list - otherwise it replaces the defaults.

    Using the special value 'ALL' will load all the MIB files that
  the library can find.


    Alternatively, the tools may be looking in the wrong place.
  The default location for the mib files is /usr/share/snmp/mibs.
  Again, this is set when the suite is first configured and compiled.
  This can be changed using the environmental variable 'MIBDIRS'
  or the snmp.conf directive 'mibdirs'.

    Note that this may very well affect you if you've installed a
  new version of the suite manually, replacing one provided by the
  supplier (which typically would use a more 'central' location).


    Finally, are you sure that you've installed the MIB files?
  If you've compiled the suite from scratch, you need to run
  "make install" at least once, before the tools will be able to
  find the MIB files.  This is unlikely to be a problem if you've
  been working with the tools for a while, but can bite those coming
  fresh to the SNMP world.



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

  This is actually the same as the previous question.  Because the tools
  don't 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.



What does "Cannot find module (XXX-MIB)" mean?
---------------------------------------------

    This is similar to the previous questions.   In this case, it's
  stating that it can't find the specified module - either becuase
  it's not installed properly, or the name used is subtly wrong.

    If it's just one or two modules that are not being found, check
  that the files are in the expected location, are readable, and the
  name being used is correct.  Note that the name reported is the
  name of the MIB module, which is not necessarily the same as the
  name of the file. See the question 'How do I add a MIB to the tools?'
  for more details on this.

    If the tool is generating a whole slew of errors, then it's
  likely that either the MIB files haven't been installed at all,
  or the library is looking in the wrong place.   See the previous
  two questions.



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 do I replace MIB values with new ones?
-----------------------------------------

  The UCD parser generally takes the first definition it sees for each
  object in the MIB hierarchy.   Even if you specify your file to be read
  first, if the IMPORTS clauses reference a MIB with competing objects,
  those objects will be parsed first.

  When specifying the Replace MIB command-line option (-PR), the parser
  will use definitions sourced from the most recent MIB file.
  The parser will replace MIB objects when the sub-identifier and name match.

  Caution: Using Replace MIB, there is NO guarantee that the resulting
  MIB tree will be correct.  Other MIB objects matching the name but
  not the sub-identifier will persist.  Sub-hierarchies may be reparented.
  In particular, random access searching [see man 1 snmpcmd]
  may give unexpected result.
  The Replace MIB option is experimental, buyer beware, carpe diem, etc.

  Here are a few considerations to help you obtain good results.
  These hold true even if you never use the Replace MIB feature.
  Your suggestions for improvement are welcomed.

    1. The parser searches the specified directories and attempt
       to parse every file whose path does not begin with "." (period).
       Remove (or rename) older MIB files from these directories.
       Rename "README" to ".README" , etc.

    2. Hint: the parser's module list is in LIFO order. You may see better
       results if the directory with the most correct MIB files is
       specified last in the MIBDIRS environment.

    3. Constrain the parser to not read in default MIB files by setting
       the MIBS environment to the environment separator character
       [semi-colon on win32, colon everywhere else].
       Setting this to "" may also have the same effect.

    4. The MIBFILES environment can specify the path of the new MIB file.

  Within a program, the call
	ds_set_boolean(DS_LIBRARY_ID, DS_LIB_MIB_REPLACE, 1 | 0)
  will enable or disable the Replace MIB feature respectively.
  If you're having problems loading a particular MIB file, this
  call can be used to disable this feature, before using read_mib() to
  load the required file, and then re-enabling the Replace MIB feature.
  (or vice versa, as appropriate).



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,
  or the tutorial at
	http://www.net-snmp.org/tutorial/commands/snmptranslate.html



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.
  


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)
	- Host Resources (RFC 1514) initial implementation
	- SNMPv3 MIBS (RFCs 2571-6)

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



What protocols are supported?
----------------------------

  The agent supports all three current versions of SNMP (v1, v2c and v3),
  over both UDP and TCP transports, as well as a SMUX (RFC 1227) master
  agent, and AgentX (RFC 2257 ) in both master and subagent roles.



How do I configure the agent?
----------------------------

  That depends on what you want it to do.  See the snmpd.conf(5) manual
  page for the possibilities.

  You can also run the "snmpconf" perl script to help you create this
  file.  Start off with 'snmpconf -g basic_setup' to get you going.



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

  While simply adding a file to the MIB directory (and possibly tweaking
  the list of MIBs to load) is sufficient for the tools, unfortunately
  extending the functionality of the agent to include this is not 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 a number of alternative 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 include) 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, it may be possible to link another agent (which already
  supports the desired MIB), as a "subagent" of the UCD master (or
  vice versa).  The possibilities here are SMUX, AgentX or proxied
  SNMP (see the next question but one).

  Finally, the agent itself can be extended to support additional MIB
  groups, by writing the necessary C code, and including this within
  the main agent - either statically compiled in, or dynamically loaded.
  This is covered further in the next section.

    Note that there is no visible difference between 'pass-through'
  MIB support, subagents, and modules implemented within the main 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 line given.
  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(5)' 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.

  

What's the difference between AgentX, SMUX and proxied SNMP?
-----------------------------------------------------------

    All three are protocols that can be used to make two or more agents
  appear as one to the querying application.  In each case, one agent
  takes the role of "master", and delegates requests to one of the others
  as and where this is appropriate.  The differences between them mainly
  relate to how data is represented, and the mechanisms for communication
  between master and subagents.

    SMUX and proxy SNMP both essentially use the standard SNMP packet format.
  The main difference is that a proxy SNMP subagent need not be aware that
  it is acting in such a role.  It typically listens on a non-standard port,
  and simply receives requests as usual, forwarded from the master agent. 
  The main issue to be aware of is that such requests will usually appear
  to come from the local host, and this may affect how the access control
  mechanisms need to be set up.

    SMUX uses a similar packet format, but the subagent "registers" with
  the master agent, providing a suitable password.  The UCD agent includes
  the possibility of acting as a SMUX master agent, but the suite does not
  include a subagent API.   Note that the SMUX protocol has essentially
  been superceded by AgentX, but is still provided in order to support
  existing SMUX subagents.
    See the file 'agent/mibgroup/README.smux' for details.

    AgentX uses a more compact (and simpler) packet format, with a richer
  range of administrative commands, and provides a more flexible and reliable
  extension mechanism.  The UCD agent can be used in both master and subagent
  roles, and the agent library can also be used to embed an AgentX subagent
  within another application.
    See the file 'README.agentx' for details.

  Note that support for SMUX is not configured in by default.  You will
  need to run configure with the option

		--with-mib-modules=smux

  Starting from release 4.2.1, AgentX support is now included by default,
  but needs to be explicitly activated in the master agent.  Do this by
  adding the line

		master agentx

  to the snmpd.conf file before starting the agent.  Note that AgentX
  support is still experimental, and should not be used on production
  systems.  See README.agentx for details.



Which should I use?
------------------

  That's a difficult question.

  Comparing the three protocols, SNMP was not originally designed
  as an internal subagent-communication protocol, and there are
  certain architectural limitations to SMUX, which were addressed
  as part of the design of AgentX.  These include such aspects as
  reliable handling of SET requests (particularly in the face of
  failures), a common value for sysUpTime, and a mechanism for
  sharing tables across multiple subagents.
    So from a purely functional point of view, AgentX is the most
  appropriate choice for subagent communication.

    However, the UCD AgentX implementation (while significantly
  more mature than it has been), is still not complete or without
  known problems.  It's probably sufficiently stable for normal
  day-to-day use, but isn't really ready for use in mission-critical
  systems.
    The proxy-SNMP support is also still experimental, and hasn't
  received the same level of active use that the AgentX code has.
  So it's uncertain quite how reliable this code might be.
    The SMUX support is the most mature of the three, so is probably
  the safest choice.  But it is no longer being actively maintained,
  as the original author has moved on, and the current developers
  don't use this facility.  If it meets your needs, then fine - but
  we can't promise to fix bugs.  (Of course, if you can supply a
  fix, then we'll update the code accordingly).  And this is only
  available as a master agent anyway.  This package does not include
  a SMUX subagent toolkit.

    This decision will probably be dictated by external considerations
  (i.e. the other agents you need to combine with).  Ideally, you
  should be looking towards AgentX, but this is not always possible.

    Note that as far as individual MIB modules are concerned, the
  protocol used to transport the request is more or less irrelevant.
  The same information is being requested (or set) each time, so
  a MIB module ought to be protocol-independent.  This was one of
  the design aims of the AgentX support, and the exact same module
  code can be included as part of a pure-SNMP master agent, or an
  AgentX subagent, with no modifications needed.
    (This could also be extended to implement a SMUX subagent,
  simply by providing a suitable driving architecture round the
  common variable-handling code.  But don't hold your breath).



How can I combine two copies of the 'mib2' tree from separate subagents?
-----------------------------------------------------------------------

  At the moment, you can't.  Sorry about that.

  Ideally, this ought to be possible by using the community string or
  the SNMPv3 context to distinguish between parallel MIB trees.  But
  support for this has not been implemented in the UCD agent.  (Though
  it is planned).
    Probably the only way to handle this at the moment, is to tweak
  one of the subagents to use a different set of (non-standard) OID
  assignments - perhaps by relocating the whole of the subtree to
  another (private) OID.

    We realise that this is not ideal, but it's the best we can offer
  at the moment.



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

  The agent sends a 'coldStart(0)' trap when it first starts up, and a
  UCD-specific trap 'ucdShutdown' when it stops.  It can also be configured
  to send an 'authenticationFailure(4)' trap when it receives an SNMPv1
  request using an unknown community name.  It does not currently generate
  either 'coldStart(0)' or 'warmStart(1)' traps on being re-configured,
  though this would be fairly simple to add.  (The main difficulty would
  be determining whether the configuration had changed or not).

    The agent does not send 'linkUp' or 'linkDown' traps.  Generating such
  traps would be simple enough, but the difficulty is in recognising when
  they should be generated.  See the question on generating traps in the
  CODING section for more discussion of this.

    With all these alerts, the agent also needs to be configured with
  (one or more) destinations to send them to, specifying the type of
  notification (v1 or v2 trap, or v2 inform) and the community name to
  use.  This uses the snmpd.conf directives 'trapsink', 'trap2sink' and
  'informsink' for the destination type, and 'trapcommunity' for the
  community name.  SNMPv3 destinations can be configured using the directive
  'trapsess'.   See the snmpd.conf man page for details.

    Note that all notifications will be sent to all destinations.  The
  agent does not (currently) support notification filtering.
 


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

  Firstly, 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.  It's also often
  useful to use the '-L' flag, to log messages to stdout.

  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.  Check the agent log file for any error messages,
  or run it with '-f -L' and see what it reports.



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

  Firstly, 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 cannot set
  any variables in the MIB" above).

    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 questions 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}

  For strict security you should use only SNMPv3, which is the secure
  form of the protocol.



How can I listen on just one particular interface?
-------------------------------------------------

    Normally, the agent will bind to the specified port on all interfaces
  on the system, and accept request received from any of them.  With
  version 4.2, the '-p' option can now be used to listen on individual
  interfaces.  For example,
	
			snmpd -p 161@127.0.0.1

  will listen (on the standard port) on the loopback interface only, and

			snmpd -p 6161@10.0.0.1

  will listen on port 6161, on the (internal network) interface with address
  10.0.0.1.   If you want to listen on multiple interfaces (but not all),
  then simply repeat this option for each one:

		snmpd -p 161@127.0.0.1 -p 161@10.0.0.1

  The AgentX port option ('-x') works in much the same way.  Unfortunately,
  this uses a slightly different syntax to specify interface and port
  number ( "-x 705:10.0.0.1" - with a ':' rather than '@').



How do I configure access control?
---------------------------------

    The simplest way is to use the configure directives:

		rocommunity public
		rwcommunity private

  These specify the community names to accept for read-only and
  read-write access to the whole of the supported MIB tree.
  (Obviously you can change these community strings to match
  your requirements - which is a particularly good idea in the
  case of 'rwcommunity'!)

    These can also be restricted to particular subtrees, and/or request
  sources.  Similarly, the configure directives 'rouser' and 'rwuser'
  can be used to allow the specified SNMPv3-authenticated users access
  to all or part of the MIB tree.  See 'snmpd.conf(5)'.

    These are effectively wrappers round the core access control
  mechanisms.  This uses four directives 'com2sec', 'group', 'view'
  and 'access',  and provides a more efficient and flexible control
  over who can access what portions of the tree.

    See the next question for the gory details.



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 exact {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" (for a particular protocol version), and the internal name used in the
  access line.  Note that the token "any" is no longer acceptable for the
  security model - the original support for this was due due to a misreading
  of the RFC.  You should replace any such line with separate versions for
  each of the desired security models ('v1', 'v2c' & 'usm').

    For SNMPv1 and SNMPv2c, the group line is 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.

    With SNMPv3, the security name is part of the basic protocol, and can
  be used directly.

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



How do I configure SNMPv3 users?
-------------------------------

    Create a file /var/ucd-snmp/snmpd.conf file, containing the line

	createUser {myUser} MD5 {myPassword} DES

  (where {myUser} and {myPassword} are the appropriate values, _without_
  the braces).  Then start (or re-start) the snmpd agent.
  This will create the new user.  See the access control entries above
  for how to use this, and the file 'README.snmpv3' for more details.



The 'createUser' line disappears when I start the agent.  Why?
-------------------------------------------------------------

    That's deliberate.   The agent removes the (human-readable) 'createUser'
  directive, and replaces it with an equivalent 'usmUser'.  This
  contains the same information, but in a form that's only meaningful
  internally.  This means that the password is not longer stored in
  a human-readable form.  Additionally, the password has been converted
  to a key that can only be used to access the local machine.  If someone
  stole the new usmUser line on this machine, they could not use that
  information to access any of your other agents.



What's the difference between /var/ucd-snmp and /usr/share/snmp?
---------------------------------------------------------------------

    Most "static" agent configuration should go in the traditional location
  (typically /usr/share/snmp/snmpd.conf).   The /var/ucd-snmp
  location is used for information set during the running of the agent,
  which needs to be persistent between one run of the agent and the next.

    Putting the 'createUser' line in this persistent file is an exception,
  for security reasons (see above).  In general you shouldn't need to put
  anything else here.



My new agent is ignoring the old snmpd.conf file. Why?
-----------------------------------------------------

    The most likely explanation is that the new version of the agent is
  looking in a different location than the previous one.  This is commonly
  experienced when replacing a ready-installed version (e.g. from a Linux
  distribution), with the current release installed from the source.

    The default location for this file with the basic distribution is
  /etc/snmp/snmpd.conf (or PREFIX/share/snmp/snmpd.conf).
  Ready-installed versions often look for the file as /etc/snmpd.conf.
  Try moving the old config file to the new location, and restart the agent.



Why am I getting "Connection refused"?
-------------------------------------

    This is actually nothing to do with the access control mechanism
  (though that's an understandable mistake).  This is the result of
  the TCP wrapper mechanism using the files 'hosts.allow' and 'hosts.deny'
  to control access to the service.  Some distributions (such as RedHat
  Linux) come with this enabled automatically - otherwise you need to
  select it explicitly by configuring using '--with-libwrap'.

    The simplest way to avoid this problem is to add the line

		snmpd: ALL

  in the file /etc/hosts.allow (or wherever this file is on your system).


 
I'm getting errors about "bad security model" - why?
----------------------------------------------------

  Until release 4.2, the access control handling accepted the token "any" 
  to cover all of the recognised security models.  This is explicitly
  forbidden in the relevant RFC, so support for this is being withdrawn.
    As an interim measure, it is currently accepted (with the warning you
  see), but this will not be the case in future releases of the agent.
 
    You should replace the token 'any' with 'v1', 'v2c' or 'usm' as
  appropriate.  If you want to support all three of these security models,
  you'll need to use three distinct group lines, one for each. See the
  example snmpd.conf file for details.

  

I'm getting errors about "bad prefix match parameter" - why?
------------------------------------------------------------

  This is similar to the previous question.  With 4.2, the syntax of the
  'access' configure line has changed, and a value of '0' is no longer
  acceptable for the sixth field.  Simply replace this with the word 'exact'.


  
Why can't I see values in the UCDavis 'extensible' or 'disk' trees?
------------------------------------------------------------------

  Both these trees are 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.

  Optionally, run snmpconf -g monitoring to help you set up this
  section of the snmpd.conf file.



Why can't I see values in the UCDavis 'memory' or 'vmstat' trees?
----------------------------------------------------------------

  These mib modules are not supported on all operating systems, and
  will not be included on any other system.  Currently, they are only
  supported on Linux, HP-UX (memory only), Solaris, BSDi (vmstat on
  BSDi4 only), FreeBSD, NetBSD and OpenBSD.
    If you want to help port it to other systems, let us know.



What do the CPU statistics mean - is this the load average?
----------------------------------------------------------

  Unfortunately, the original definition of the various CPU statistics
  was a little vague.  It referred to a "percentage", without specifying
  what period this should be calculated over.  It was therefore
  implemented slightly differently on different architectures.

    The 4.2 release includes "raw counters", which can be used to
  calculate the percentage usage over any desired period.  This is
  the "right" way to handle things in the SNMP model.

    Note that this is different from the Unix load average, which is
  available via the loadTable, and is supported on all architectures.



What about multi-processor systems?
----------------------------------

    Sorry - the CPU statistics (both original percentages, and the
  newer raw statistics) both refer to the system as a whole.  There
  is currently no way to access individual statistics for a particular
  processor.

    Note that although the Host Resources table includes a hrProcessorTable,
  the current implementation suffers from two major flaws.  Firstly, it
  doesn't currently recognise the presence of multiple processors, and
  simply assumes that all systems have precisely one CPU.  Secondly, it
  doesn't calculate the hrProcessorLoad value correctly, and either returns
  a dummy value (based on the load average) or nothing at all.

    If you want to monitor a multi-processor system, you're currently
  out of luck.   But you've got the source, so you can always have a
  go yourself :-)



The speed/type of my network interfaces is wrong - how can I fix it?
-------------------------------------------------------------------

    Some operating systems will provide a mechanism for determining
  the speed and type of network interfaces, but many do not.  In this
  case, the agent attempts to guess the most appropriate values, based
  on the name of the interface.
    Version 4.2 allows you to override these guessed values, using the
  configuration directive 'interface', specifying the name, type and
  speed of a particular interface.  This is particularly useful for
  fast-ethernet, or dial-up interfaces, where the speed cannot be
  guessed from the name.
    See the snmpd.conf(5) man page for details.
  


The interface statistics for my subinterfaces are all zero - why?
----------------------------------------------------------------

    Unfortunately, most kernels that support multiple logical
  interfaces on a single physical interface, don't keep separate
  statistics for each of these.  They simply report the overall
  statistics for the physical interface itself.
    There's no easy way around this problem - the agent can only
  report such values as it can find out.  If the kernel doesn't
  keep track of these figures, the agent can't report them.
    Sorry!


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 'net-snmp-coders@lists.sourceforge.net'
		Remember to tell us what architecture you have!



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.  (It won't fix the underlying problem,
  but at least you won't be nagged about it).



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 will normally continue
  to run without this level of access permission, but won't be able to
  report values for many of the variables (particularly those relating
  to network statistics).

 

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 run snmpconf to help you create one.
    See the snmpd.conf(5) manual page for further details.



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 configuring in the system portion 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 relatively immature implementation, and has only not
  received a great deal of development.  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.

  Basically, if the information returned is wrong on your architecture,
  tell us how to get the correct values, and we'll try and fix it.



CODING
======

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

  Run configure with --with-cc=cc


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



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

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

    The code can be included within the agent itself, statically configured
  and linked in when the agent is compiled.  Alternatively, with the 4.2
  release of the agent, it's possible to dynamically load MIB modules once
  the agent is running.  Finally, the agent can be configured to pass certain
  portions of the MIB tree off to one or more subagents.  See the earlier
  question on AgentX, SMUX and proxied SNMP for more details.

    All three mechanisms use the same module 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.

    Note that the UCD suite does not include support for SMUX subagents.



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.



I've created a new module with 'mib2c' but it doesn't work.  Why not?
--------------------------------------------------------------------

    Remember that 'mib2c' generates a template for the MIB implementation.
  It doesn't fill in all the details for you.  In particular, it cannot
  know how to obtain the information needed to answer particular queries.
  That's the job of the MIB module programmer (you!) -  See the previous
  question for how to proceed.

    Essentially mib2c handles the syntax of the MIB implementation,
  leaving you to concentrate on the semantics.



Where should I put the files produced by 'mib2c'?
------------------------------------------------

  If you're using the main source tree to compile your new module, then
  put these two files (mymib.[ch]) in the directory 'agent/mibgroup'.
  You should then re-run configure to add in your new module
  ("configure --with-mib-modules=mymib") and recompile.

    If you've got a number of new modules to add, it might be
  sensible to put them all into a single subdirectory of 'mibgroup'.
  Then create a header file, listing the individual components.
  This might look something like:

		config_require(mymib/myObjects)
		config_require(mymib/myTable)
		config_require(mymib/myOtherTable)

  If this was saved as the file 'mymib.h', then the same configure
  line given above, would pull in all three modules.  See the
  current contents of 'agent/mibgroup' for examples of this.



Mib2c only handles a single table in my MIB. How can I fix this?
---------------------------------------------------------------

    This is a bug in the mib2c script, which has been corrected with
  the 4.2 release.  Earlier versions can be fixed by applying the
  following patch:

	$ diff -u mib2c.cln mib2c
	--- mib2c.cln   Wed Nov 29 15:12:47 2000
	+++ mib2c       Wed Nov 29 15:13:18 2000
	@@ -132,6 +132,6 @@
	 #============================================
	 foreach $vtable (@table_list) {
	     foreach $ptable (@processtable) {
	-       $variables{$ptable}{'processed'} = 
	+       $variables{$ptable}{'processed'} .= 
	            (eval "\"$variables{$ptable}{'code'}\"") . "\n\n";
	     }



Mib2c complains about a missing "mib reference" - what does this mean?
---------------------------------------------------------------------

    This basically means that it hasn't loaded the MIB file containing
  the definition of the MIB subtree you're trying to implement.  This
  might be because it hasn't been installed, the name is wrong, or
  (most likely), because it isn't in the default list.  See the MIBS
  section for more details.



How can I get the agent to generate a trap (or inform)?
------------------------------------------------------

    Actually generating a trap is reasonably simple - just call one
  of the utility routines 'send_easy_trap()' or 'send_v2trap' with
  the relevant information (trap values, or varbind list respectively).
  See the 'snmp_trap_api(3)' man page for details.

    Determining _when_ to generate the trap is often harder.
  If the trap is generated in response to some action within the
  agent, (e.g. as the result of a SET), then this isn't too much
  of a problem.

    But if the trap is intended to report on a change of status
  (e.g. a network interface going up or down, or a disk filling up),
  then actually detecting this is non-trivial.   It's necessary to
  poll the value(s) on a regular basis, save the results and compare
  them with the new values the next time round.
    This can be done using the routines documented in 'snmp_alarm(3)',
  though unfortunately we don't have any examples of how to do this.
  Eventually, the intention is to implement the Event MIB (from the
  Distributed Management working group), which will provide this
  functionality in a flexible, standardised manner.

    In the meantime, the simplest approach is probably to set up
  an external program, to poll the agent for the desired values,
  and generate a trap when values change.  E.g:

		old_value=`snmpget myObject.0`
		while true
		do
		    sleep 60
		    new_value=`snmpget myObject.0`
		    if [ $old_value != $new_value ]
		    then
			snmptrap .... myObject.0 i $new_value
		    fi
		    old_value=$new_value
		done

   (Obviously, this is not complete, but should give you the
   general idea).



I'm getting an error "autoheader: not found" - what's wrong?
-----------------------------------------------------------

    This usually apears when compiling the current development source
  version, obtained via CVS.  Unfortunately, the timestamps on some of
  the configure files are such that make assumes (mistakenly) that the
  configure script needs to be re-generated.
    A similar problem may arise relating to 'autoconf'.

    In both cases, this can be corrected by running the command
  "make -k touchit" before attempting to make the main package.



Why is the project workspace empty under Visual C++?
---------------------------------------------------

    This is probably due to the different ways that Unix and Windows
  handle text file line termination.  Older versions of WinZip don't
  handle this properly, and Visual C++ gets confused (poor dear!).
  The latest version of WinZip is reported to unpack this correctly.



Why are packets requesting the same information larger with UC-Davis SNMP ?
-------------------------------------------------------------------------

    This shouldn't happen with version 4.2 or later, but for older
  version the following still applies:

    Some users note that UCD-SNMP applications always generate larger PDUs
  than other SNMP packages, even if the information requested is the same.
  Further, there are some agents that refuse PDUs from UCD-SNMP applications
  but accept PDUs from other applications.

  UCD-SNMP is based on the CMU code from a long time ago which encoded things
  using the long form of length encoding.  Some agents use the short form
  of length encoding only, and do not understand the long form.

    Get version 4.2 or higher to user th shorter encoding lengths.

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.



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)

  And an alternate, added 26-Apr-2000:
  
  "In theory, it shouldn't be that hard, but it just needs to be done."