snmp.sgml

eCos/RedBoot for勤研ARM AnywhereII(4510) 含全部源代码

<PROGRAMLISTING>
typedef struct trap {
        unsigned char ip [4];
        unsigned int  port;
        unsigned char community [256];
}

trap            trapsink;
unsinged char   sink [16]; 

...
...

if (trapsink.ip != 0) {
        sprintf (sink, "%d.%d.%d.%d",
                 trapsink[0], trapsink[1], trapsink[2], trapsink[3]);
        if (create_trap_session (sink,
                trapsink.port,
                (char *)trapsink.community,
                SNMP_VERSION_1,
                SNMP_MSG_TRAP) == 0) {
                log_error ("Creation of trap session failed \n");
        }
}
</PROGRAMLISTING>
</SECT2>
<SECT2 id="net-snmp-snmpd-conf">
<TITLE><LITERAL>snmpd.conf</LITERAL> file</TITLE>
<PARA>
Using snmpd.conf requires the inclusion of one of the file-system packages
(eg. CYGPKG_RAMFS) and CYGPKG_FILEIO. With these two packages included, the
SNMP sub-system will read the snmpd.conf file from the location specified in
<LITERAL>SNMPCONFPATH</LITERAL>, or the standard builtin locations, and use
these profiles. Only the profiles specified in the <LITERAL>ACCESS-CONTROL</LITERAL>
section of <link linkend="net-snmp-agent-manpages-snmpd.conf">snmpd.conf</link> file have 
been tested and shown to work. Other profiles which have been implemented in 
<LITERAL>UCD-SNMP-4.1.2</LITERAL>'s <LITERAL>snmpd.conf</LITERAL> may not work
because the sole purpose of adding support for the snmpd.conf file has been to
set up <LITERAL>ACCESS-CONTROL</LITERAL> models.
</PARA>
<PARA>
At startup, the SNMP module tries to look for file <FILENAME>snmp.conf</FILENAME>. 
If this file is not available, the module successively looks for files
<FILENAME>snmpd.conf</FILENAME>, <FILENAME>snmp.local.conf</FILENAME> and 
<FILENAME>snmpd.local.conf</FILENAME> at the locations pointed to by <LITERAL>
SNMPCONFPATH</LITERAL> environment variable. In case <LITERAL>SNMPCONFPATH
</LITERAL> is not defined, the search sequence is carried out in default directories.
The default directories are :<FILENAME>/usr/share/snmp</filename>, <filename>
/usr/local/share/snmp</filename> and <filename>$(HOME)/.snmp</filename>.
The configurations read from these files are used to control both, SNMP 
applications and the SNMP agent; in the usual UNIX fashion.
</PARA>
<PARA>
The inclusion of snmpd.conf support is enabled by default when suitable 
filesystems and FILEIO packages are active.
</PARA>
</SECT2>
</SECT1>
<SECT1 id="net-snmp-test-cases">
<TITLE>Test cases</TITLE>
<PARA>
Currently only one test program is provided which uses SNMP.
</PARA>
<PARA>
"snmpping" in the SNMP agent package runs the ping test from
the TCPIP package, with the snmpd running also. This allows you
to interrogate it using host tools of your choice. It supports MIBs
as documented above, so eg. <COMMAND>snmpwalk
<REPLACEABLE>&lt;hostname&gt;</REPLACEABLE> public dot3</COMMAND> under
Linux/UNIX should have the desired effect.
</PARA>
<PARA>
For serious testing, you should increase the length of time
the test runs by setting CYGNUM_SNMPAGENT_TESTS_ITERATIONS
to something big (e.g., 999999). Build the test
(<COMMAND>make -C net/snmp/agent/current tests</COMMAND>)
and run it on the target.
</PARA>
<PARA>
Then start several jobs, some for pinging the board (to make
the stats change) and some for interrogating the snmpd. Set &dollar;IP
to whatever IP address the board has:
</PARA>
<PROGRAMLISTING>
# in a root shell, for flood ping
while(1)
date
ping -f -c 3001 &dollar;IP
sleep 5
ping -c 32 -s 2345 &dollar;IP
end</PROGRAMLISTING>
<PROGRAMLISTING>
# have more than one of these going at once
setenv MIBS all
while (1)
snmpwalk -OS &dollar;IP  public
date
end</PROGRAMLISTING>
<PARA>
Leave to run for a couple of days or so to test stability.
</PARA>
<PARA>
The test program can also test snmpd.conf support. It tries to build a minimal
snmpd.conf file on a RAM filesystem and passes it to the snmp sub-system. With
this profile on target, the following snmp[cmd] (cmd=walk, get, set) should
work :
</PARA>
<PROGRAMLISTING>
snmp[cmd] -v1 $IP crux $OID
snmp[cmd] -v2 $IP crux $OID
snmp[cmd] -v3 $IP -u root -L noAuthNoPriv $OID
snmp[cmd] -v3 $IP -u root -L authNoPriv -A MD5 -a md5passwd $OID
</PROGRAMLISTING>
<PARA>
The following commands would however fail since they violate the access model :
</PARA>
<PROGRAMLISTING>
snmp[cmd] $IP public $OID
snmp[cmd] -v1 $IP public $OID
snmp[cmd] -v2c $IP public $OID
snmp[cmd] -v3 $IP -u no_user -L noAuthNoPriv $OID
snmp[cmd] -v3 $IP -u root -L authNoPriv -A MD5 -a badpasswd $OID
</PROGRAMLISTING>
</SECT1>
<SECT1 id="net-snmp-clients-and-package-use">
<TITLE>SNMP clients and package use</TITLE>
<PARA>
SNMP clients may use these packages, but this usage is currently
untested: the reason why this port to eCos exists is to acquire
the SNMP agent.  The fact that that the SNMP API (for clients) exists
is a side-effect.  See the standard man page SNMP_API(3)
for details.  There are further caveats below about client-side
use of the SNMP library.
</PARA>
<PARA>
All of the SNMP header files are installed beneath .../include/ucd-snmp
in the install tree.  The SNMP code itself assumes that directory
is on its include path, so we recommend that client code does the
same.  Further, like the TCP/IP stack, compiling SNMP code
requires definition of _KERNEL and __ECOS,
and additionally IN_UCD_SNMP_SOURCE.
</PARA>
<PARA>
Therefore, add all of these to your compile lines if you wish
to include SNMP header files:
</PARA>
<PROGRAMLISTING>-D_KERNEL 
-D__ECOS 	
-DIN_UCD_SNMP_SOURCE=1	 	
-I&dollar;(PREFIX)/include/ucd-snmp</PROGRAMLISTING>
</SECT1>
<SECT1 id="net-snmp-unimplemented-features">
<TITLE>Unimplemented features</TITLE>
<PARA>
Currently, the filesystem and persistent storage areas are
left undone, to be implemented by the application.
</PARA>
<PARA>
The SNMP library package is intended to support client and
agent code alike.  It therefore contains lots of assumptions about
the presence of persistent storage ie. a filesystem.  Currently,
by default, eCos has no such thing, so those areas have been simply
commented out and made to return empty lists or say &ldquo;no
data here.&rdquo;
</PARA>
<PARA>
Specifically the following files have omitted/unimplemented code :
</PARA>
<PARA>
<filename>PACKAGES/net/snmp/lib/VERSION/src/parse.c</filename>
</PARA>
<PARA>
contains code to enumerate MIB files discovered in the system
MIB directories (&ldquo;<filename>/usr/share/snmp/mibs</filename>&rdquo;),
and read them all in, building data structures that are used by
client programs to interrogate an agent.  This is not required in
an agent, so the routine which enumerates the directories returns
an empty list.
</PARA>
<PARA>
<filename>PACKAGES/net/snmp/lib/VERSION/src/read_config.c</filename>
contains two systems:
</PARA>
<PARA>
The first tries to read the configuration file as described in the
<link linkend="net-snmp-configuring-ecos">snmpd.conf file</link> section and 
the second system contains code to record persistent data as files in a
directory (typically <filename>/var/ucd-snmp</filename>) thus preserving the 
state permanently.
</PARA>
<PARA>
The first part is partially implemented to support multiple profiles and enables
dispatcher functionality as discussed in <xref linkend="net-snmp-version-usage">.
The second part is not supported at all in the default implementation. As required, 
a cleaner interface to permit application code to manage persistent data will be 
developed in consultation with customers.
</PARA>
</SECT1>
<SECT1 id="net-snmp-mib-compiler">
<TITLE>MIB Compiler </TITLE>
<PARA>In the directory
	  <filename>/snmp/agent/VERSION/utils/mib2c</filename>,
there are the following files:</PARA>
<PROGRAMLISTING>
README-eCos             notes about running with a nonstandard 
                        perl path.
README.mib2c            the README from UCD; full instructions on
                        using mib2c   
mib2c                   the perl program
mib2c.conf              a configuration file altered to include the
                        eCos/UCD   
mib2c.conf-ORIG         copyright and better #include paths; and
                        the ORIGinal.   
mib2c.storage.conf      other config files, not modified.   
mib2c.vartypes.conf
</PROGRAMLISTING>
<PARA>
mib2c is provided BUT it requires the SNMP perl package SNMP-3.1.0,
and that in turn requires perl nsPerl5.005_03 (part of
Red Hat Linux from 6.0, April 1999).</PARA>
<PARA>These are available from the CPAN (&ldquo;the Comprehensive
Perl Archive Network&rdquo;) as usual;
<ulink url="http://www.cpan.org/">http://www.cpan.org/</ulink>
and links from there. Specifically:
</PARA>
<itemizedlist>
<listitem><PARA>
PERL itself:
<ulink url="http://people.netscape.com/kristian/nsPerl/">
http://people.netscape.com/kristian/nsPerl/
</ulink></para></listitem>
<listitem><para>
<ulink url="http://people.netscape.com/richm/nsPerl/nsPerl5.005_03-11-i686-linux.tar.gz">
http://people.netscape.com/richm/nsPerl/nsPerl5.005_03-11-i686-linux.tar.gz
</ulink></para></listitem>
<listitem><para>
SNMP.pl
<ulink url="http://www.cpan.org/modules/01modules.index.html">
http://www.cpan.org/modules/01modules.index.html
</ulink></para></listitem>
<listitem><para>
<ulink url="http://cpan.valueclick.com/modules/by-category/05_Networking_Devices_IPC/SNMP/">
http://cpan.valueclick.com/modules/by-category/05_Networking_Devices_IPC/SNMP/
</ulink></para></listitem>
<listitem><para>
<ulink url="http://www.cpan.org/authors/id/G/GS/GSM/SNMP.tar.gz">
http://www.cpan.org/authors/id/G/GS/GSM/SNMP.tar.gz
</ulink></para></listitem>
</itemizedlist>
<PARA>(note that the .tar.gz files are not browsable)</PARA>
<PARA>
For documentation on the files produced, see the documentation
available at
<ulink url="http://ucd-snmp.ucdavis.edu/">http://ucd-snmp.ucdavis.edu/
</ulink>
in general, and file <filename>AGENT.txt</filename> in particular.
</PARA>
<PARA>
It is likely that the output of mib2c will be further customized
depending on eCos customer needs; it&rsquo;s easy to do this
by editing the mib2c.conf file to add or remove whatever you need
with the resulting C sources.
</PARA>
<PARA>
The UCD autoconf-style configuration does not apply to eCos.
 So if you add a completely new MIB to the agent, and support it
using mib2c so that the my_new_mib.c file contains
a init_my_new_mib() routine to register
the MIB handler, you will also need to edit a couple of control
files; these claim to be auto-generated, but in the eCos release,
they&rsquo;re not, don&rsquo;t worry.
</PARA>
<PROGRAMLISTING>PACKAGES/net/snmp/agent/VERSION/include/mib_module_includes.h</PROGRAMLISTING>
<PARA>
contains a number of lines like
</PARA>
<PROGRAMLISTING>#include &ldquo;mibgroup/mibII/interfaces.h&rdquo;</PROGRAMLISTING>
<PARA>
so add your new MIB thus:
</PARA>
<PROGRAMLISTING>#include &ldquo;mibgroup/mibII/my_new_mib.h&rdquo;</PROGRAMLISTING>
<PROGRAMLISTING>PACKAGES/net/snmp/agent/VERSION/include/mib_module_inits.h </PROGRAMLISTING>
<PARA>
contains a number of lines like
</PARA>
<PROGRAMLISTING>init_interfaces();         
init_dot3(); </PROGRAMLISTING>
<PARA>
and so on; add your new MIB as follows:
</PARA>
<PROGRAMLISTING>init_my_new_mib(); </PROGRAMLISTING>
<PARA>
and this should work correctly.
</PARA>
</SECT1>

&net-snmp-agent-snmp-manpages-sgml
</CHAPTER>
</PART>