The smidump program is used to dump the contents of a single MIB
or PIB
module or a collection of modules to stdout in a selectable output
format. This format may be a simple tree of nodes, types or imported
modules, but also a format fully compliant to SMIv1, SMIv2, SPPI or SMIng or
CORBA IDL or C source code. Smidump can thus be used to convert
modules from SMIv2 to SMIng and from SMIng to SMIv2, or to develop
template based agent code.
OPTIONS
-V, --version
Show the smidump version and exit.
-h, --help
Show a help text and exit. The help text contains a list of all
supported output formats.
-c file, --config=file
Read file instead of any other (global and user)
configuration file.
-f format, --format=format
Use format when dumping a module. Supported output formats are described
below. The default output format is SMIng. The format argument is
case insensitive.
-l level, --level=level
Report errors and warnings up to the given severity level. See
the smilint(1) manual page for a description of the error levels. The
default error level is 3.
-s, --severity
Show the error severity in brackets before error messages.
-m, --error-names
Show the error names in braces before error messages.
-o name, --output=name
Write the output in one or multiple files instead of stdout. The file
name(s) are derived from the
name argument. Not all format
support this option.
-p module, --preload=module
Preload the module module before reading the main module(s). This may
be helpful if an incomplete main module misses to import some definitions.
-q, --quiet
Suppress comments from dumped modules. What kind of information
gets suppressed depends on the output format.
-u, --unified
Dump a unified output in case of multiple module(s) instead of
multiple concatenated output sections. This is not supported for all
output formats.
module(s)
These are the module(s) to be dumped. If a module argument represents a
path name (identified by containing at least one dot or slash character),
this is assumed to be the exact file to read. Otherwise, if a module is
identified by its plain module name, it is searched according to libsmi
internal rules. See smi_config(3) for more details.
OUTPUT FORMATS
The smidump program supports the following output formats:
sming
SMIng compliant format as defined in the SMIng Internet-Draft.
smiv2
SMIv2 compliant format as defined in RFC 2578, RFC 2579, RFC 2580.
smiv1
SMIv2 compliant format as defined in RFC 1155, RFC 1212, RFC 1215.
sppi
SPPI compliant format as defined in RFC 3159. If the underlying module
is not SPPI, there might be some mandatory information missing.
mosy
Format generated by the mosy compiler.
imports
Import hierarchy of a module.
types
Types defined in a module.
tree
OID registration tree structure of a module.
metrics
Metrics derived from a module (experimental).
identifiers
List of identifiers defined in a module.
compliances
Compliance definitions with all included objects and notifications.
corba
CORBA IDL and OID definitions following the JIDM specification translation
rules.
netsnmp
C source code files for usage within the net-snmp package (experimental).
scli
ANSI C manager stubs for usage within the scli package (experimental).
cm
Reverse engineered conceptual model in DIA XML file format (experimental).
svg
SVG diagram of a module (experimental). Use with -u when dumping multiple modules.
jax
Java AgentX sub-agent classes in separate files (experimental).
perl
Perl represention of the MIB module
(contributed by Martin Schulz <schulz@videotron.ca>).
python
Python dictionaries represention of the MIB module
(contributed by Pat Knight <pat@ktgroup.co.uk>).
xml
SMI in XML format (experimental).
xsd
SMI in XML schema format (experimental).
sizes
SNMP best case / worst case PDU sizes for typical PDUs (experimental).
EXAMPLE
This example converts the SMIv2 module IF-MIB in the current directory
to IF-MIB.sming in SMIng format. Note that the ./ prefix is used to
ensure reading the module from the current directory and not from a
place that libsmi guesses on its own.
(C) 1999-2004 F. Strauss, TU Braunschweig, Germany <strauss@ibr.cs.tu-bs.de>
(C) 1999-2002 J. Schoenwaelder, TU Braunschweig, Germany <schoenw@ibr.cs.tu-bs.de>
(C) 2002-2003 J. Schoenwaelder, University of Osnabrueck, Germany
(C) 2003-2004 J. Schoenwaelder, International University Bremen, Germany
(C) 2001-2002 T. Klie, TU Braunschweig, Germany <tklie@ibr.cs.tu-bs.de>
(C) 2002 M. Bunkus, TU Braunschweig, Germany <bunkus@ibr.cs.tu-bs.de>
and contributions by many other people.
