FAQ:General (Full text)

From Net-SNMP Wiki
(Redirected from FAQ:General Full)
Jump to: navigation, search

This section covers issues related to the project as a whole.

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:

Web page:

Sourceforge Project page:

Mirrors (note that sourceforge download servers are mirrored themselves):

What documentation is available?

  • This FAQ (!)
  • README and individual READMEs for various platforms
  • README.thread (discusses threading issues)
  • INSTALL
  • PORTING
  • EXAMPLE.conf
  • man pages for the individual tools, files and the API
at http://www.net-snmp.org/man/
  • A guide for extending the agent
  • Tutorials for both net-snmp v5 and the older ucd-snmp (v4)
at http://www.net-snmp.org/tutorial-5/
and http://www.net-snmp.org/tutorial/ respectively

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

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

There is also a Wiki (including a community-maintained version of this FAQ) at:

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

(But I guess you probably already know that :-))

Are there binaries available?

There are binaries for some version/systems available under the net-snmp-binaries package on the SourceForge Files page, which is linked to from the main project download web page at http://www.net-snmp.org/download.html. These binaries are also available on the project FTP site, with a link on the same web page.

There is also a mirror at ftp://ftp.freesnmp.org/mirrors/net-snmp/

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 move to SourceForge was 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.x line saw the last releases made using the ucd-snmp name, and all releases on this line have been bug-fixes only. Release 5.0 was the first version released under the Net-SNMP name, and all further development is being done on the 5.x code base. The 4.2.x code line is now effectively closed down, as are the older 5.x branches.

Much of the work done for the various 5.x releases has involved some fairly significant changes to the code - in particular the architecture of the agent. However attempts have been made to retain backwards compatibility as much as possible, and most code written for earlier releases should continue to work. The most visible change from the 4.2.x UCD suite to the 5.x Net-SNMP releases was a restructuring of the header file organisation - not least a change from <ucd-snmp/xxx.h> to <net-snmp/yyy.h>.

But given the maturity of the Net-SNMP code, this should be less of a consideration for most current SNMP development projects.

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:

  • Linux (kernels 2.6 to 1.3)
  • Solaris/SPARC (11 to 2.3), Solaris/Intel (10, 9) -- see README.solaris
  • HP-UX (11.31 to 9.01) -- see README.hpux11
  • Mac OS X (10.5 to 10.1) -- see README.osX
  • NetBSD (2.0 to 1.0)
  • FreeBSD (7.0 to 2.2)
  • OpenBSD (4.0 to 2.6)
  • BSDi (4.0.1 to 2.1)
  • AIX (6.1, 5.3, 5.2, 5.1, 4.3.3, 4.1.5, 3.2.5) -- see README.aix
  • IRIX (6.5 to 5.1)
  • OSF (4.0, 3.2 and Tru64 Unix 5.1B) -- see README.tru64
  • SunOS 4 (4.1.4 to 4.1.2)
  • Ultrix (4.5 to 4.2)
  • Dynix/PTX 4.4
  • QNX 6.2.1A


We have also been informed about a port to the Stratus VOS. See http://ftp.stratus.com/vos/network/network.html for details.

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

Certain systems 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 where people have reported problems that we think we've subsequently fixed!)

What happens if mine isn't listed?

It's probably worth trying to compile it anyway. Unless your system is significantly different to the supported configurations, most of the code (library, applications and the agent infrastructure) should probably compile with little or no difficulty. The most likely source of problems will be MIB modules within the agent, as this tends to be where the most system-specific code is found.

If only a few modules fail to compile, try removing them from the agent by running configure --with-out-mib-module=xxx,yyy, and re-compiling. If a large number of modules fail, then it might be easier to start from a relatively bare system, using configure --enable-mini-agent --with-defaults. Then if this minimal agent compiles and runs successfully, try adding each of the missing mibgroups using the configure option --with-mib-module.

If configure fails with "invalid configuration" messages, or you get completely stuck, contact the coders list for advice. Similarly, if you manage to get this working on a new system, please let us know of any code changes that you needed to make, together with 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!

Does it run on Windows?

The suite should compile and run on Win32 platforms, including the library, command-line tools and the basic agent framework. Note that the agent now includes support for the MIB-II module, but this requires Microsoft's Core Platform SDK. Instructions for how to install this are given in README.win32.

Pre-compiled binaries are available from the project web site.

As of v5.4, the Net-SNMP agent is able to load the Windows SNMP service extension DLLs by using the Net-SNMP winExtDLL extension.

Some other Net-SNMP MIB modules, including the UCD pass-through extensions, do not currently work under Windows. Volunteers to assist with these missing modules are likely to welcomed with open arms :-)

Further details of Windows support (currently Visual C++, MinGW 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).

Advance notice of upcoming releases are also made on the net-snmp-users list (for "release candidates") for a week or two before the full release, and on the net-snmp-coders list (for "pre-releases") during the period prior to this.

Major code revisions may be announced more widely, but these lists are the most reliable way to keep in touch with the status of the 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 a #net-snmp IRC channel set up on the freenode.net chat system. You can connect to this via chat.freenode.net. See http://www.freenode.net/ for more information on getting started with IRC.

Several core developers hang out on this channel on a fairly regular basis.

How do I submit a patch or bug report?

Bug Reports

The best way to submit a bug report is via 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 configuration or command that triggers the problem and a copy of any output produced.

Questions about using the package should be directed at the net-snmp-users@lists.sourceforge.net mailing list. Note that this mailing list is relatively busy, and the people answering these questions are doing so out of the goodness of their hearts, and in addition to their main employment. Please note the following:

  • use plain text mail, rather than HTML
  • don't resend questions more than once
    (even if no-one answered immediately)
  • include full details of exact commands and error messages
    ("I've tried everything, and it doesn't work" isn't much use!)
  • do NOT send messages to -users and -coders mailing lists
    (most developers read both anyway)
  • don't mail the developers privately - keep everything on the list

We can't promise to be able to solve all problems, but we'll certainly try and help. But remember that this is basically an unsupported package. It's Open Source, so if you need something fixing badly enough, fundamentally it's up to you to do the work.

Patches

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 the patch manager doesn't contain a decent description field.

The best way to submit patch (diff) information is by checking out the current code from the development SVN trunk, making your changes and then running "svn diff" after you're done.

If you're working from a source code distribution, and comparing old and new versions of a code file, use "diff -u OLDFILE NEWFILE"

Can I reuse the code in my commercial application?

The details of the COPYRIGHTs on the package can be found in the COPYING file. You should have your lawyer read this file if you wish to use the code in your commercial application. We will not summarize here what is in the file, as we're not lawyers and are unqualified to do so.

What's the difference between SNMPv1, SNMPv2 and SNMPv3?

What's the difference between SNMPv2 and SNMPv2c?

A full description is probably beyond the scope of this FAQ. Very briefly, the original protocol and admin 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 number of revised frameworks were developed to try and address these problems. Unfortunately, it proved difficult to achieve any sort of agreement - particularly over the details of the administrative framework to use.

There was less disagreement over the proposed changes to the protocol operations. These included:

  • increasing the range of errors that could be reported
  • introducing "exception values"
    so a single missing value didn't affect the other varbinds in the same request)
  • a new GETBULK operation
    (a supercharged GETNEXT)
  • new notification PDUs
    (closer in structure to the other request PDUs)

Strictly speaking, it's this revised protocol (originally defined in RFC 1905, and most recently in RFC 3416) that is "SNMPv2".

The only framework based on this protocol that saw a significant level of use was "Community-based SNMPv2" or "SNMPv2c" (defined in RFC 1901). This retained the same administrative framework as SNMPv1 (with all of the accompanying limitations), but using the new protocol operations.

More recently, a new administrative framework has been developed, building on the various competing SNMPv2 proposals, and using the same SNMPv2 protocol operations. This is SNMPv3, which is defined in RFCs 3411-3418. It addresses some of the deficiencies of the community-based versions, including significant improvements to the security of SNMP requests (like it finally has some!). SNMPv3 is now a full IETF standard protocol.

Strictly speaking, SNMPv3 just defines a fairly abstract framework, based around the idea of "Security Models" and "Access Control Models". It's this combination of SNMPv3 plus accompanying models that actually provides a working SNMP system. However, the only models in common use are the "User-based Security Model" (RFC 3414) and the "View-based Access Control Model" (RFC 3415). So "SNMPv3" is frequently used to mean the combination of the basic SNMPv3 framework with these two particular models. This is also sometimes described as "SNMPv3/USM".


So in brief:

  • SNMPv2c updated the protocol operations but left the administrative framework unchanged.
  • SNMPv3 updated the administrative framework but left the protocol operations unchanged.

Which versions of SNMP are supported in this package?

This package currently supports the original SNMPv1 (RFC 1157), Community-based SNMPv2 (RFCs 1901-1908), and SNMPv3 (RFCs 3411-3418). 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) was dropped with the 4.0 release of the UCD-snmp package.

Can I use SNMPv1 requests with an SNMPv2 MIB (or vice versa)?

Yes.

The syntax used to specify a MIB file (better referred to as SMIv1 or SMIv2) is purely concerned with how to define the characteristics of various management objects. This is (almost) completely unrelated to the versions of the protocol used to operate on these values. So it is quite reasonable to use SNMPv1 requests on objects defined using SMIv2, or SNMPv2 (or SNMPv3) requests on objects defined using SMIv1.

The one exception is objects of syntax Counter64, which are only accessible using SNMPv2 or higher. SNMPv1 requests will either treat such objects as an error, or skip them completely.

Note that SMIv1 is effectively obsolete, and all new MIBs should be written using SMIv2.

Where can I find more information about network management?

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

   http://www.simpleweb.org/
http://www.snmplink.org/
http://www.mibdepot.com/

The SNMP Usenet newsgroup is now mostly defunct, but although the FAQ hasn't been updated for a while, it still contains a large amount of useful information relating 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 any of the Web sites above.

Is Net-SNMP thread safe?

Strictly speaking, no. However, it is possible to use the library within a multi-threaded management application. 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 Net-SNMP agent has not been designed for multi-threaded use. It should be safe to use the agent library to embed a subagent within a threaded application as long as *all* SNMP-related activity (including generating traps, and parsing MIBs) is handled within a single thread.

The command-line tools shipped as part of the Net-SNMP distribution are simple single-threaded applications, and are not designed for multi-threaded use. Adapting these to a threaded model is left as an exercise for the student.
The same holds true for the notification receiver (snmptrapd).

Unfortunately, the SNMPv3 support was added about the same time as the thread support and since they occurred in parallel the SNMPv3 support was never checked for multi-threading correctness. It is most likely that it is not thread-safe at this time.

Other FAQ Sections

The other sections are:

   FAQ:General
   FAQ:Applications
   FAQ:Perl
   FAQ:MIBs
   FAQ:Agent
   FAQ:Compiling
   FAQ:Coding
   FAQ:Misc