Bernd> I've implemented a small table MIB:
Bernd> ----------------------------------------
Bernd> dwzTable OBJECT-TYPE
Bernd> SYNTAX SEQUENCE OF dwzList
Bernd> MAX-ACCESS not-accessible
Bernd> STATUS current
Bernd> DESCRIPTION "process name"
Bernd> ::= { bdfprocs 4 }
Bernd> dwz OBJECT-TYPE
Bernd> SYNTAX dwzList
Bernd> MAX-ACCESS not-accessible
Bernd> STATUS current
Bernd> DESCRIPTION "dwz field list"
Bernd> INDEX { dwzProcName }
Bernd> ::= { dwzTable 1 }
Bernd> dwzList ::= SEQUENCE
Bernd> {
Bernd> dwzProcName DisplayString,
Bernd> dwzProcTrace DisplayString,
Bernd> ...
Bernd> }
Bernd> ...
First, I would rename dwz to dwzEntry and dwzList to DwzEntry. (It is
just a naming conventions but it is nevertheless useful.)
Bernd> The above defines a table dwzTable with rows of dwz, where
Bernd> dwzProcName is a unique identifier for the current row of dwz.
Bernd> To create an instance of dwz, I issue the following command
Bernd> line:
Bernd> set iid "0x[join [split [mib scan $dwzProcName "myproc"] {:}] {.0x}]"
Bernd> $session instance dwzProcName.$iid myvar "somevalue"
Bernd> The first line tries to convert the processname into a unique
Bernd> object identifier - IMO this code looks rather ugly.
Bernd> Q1: Is there some easier way to convert a string index for an
Bernd> SNMP table ?
Your example is only correct if you have fixed length strings (see
below). In this case, you can simplify the conversion because Tnm
allows to have hex-values in an object identifier if they are
seperated by a colon instead of a dot (see mib(n)):
set iid [mib scan $dwzProcName "myproc"]
$session instance dwzProcName:$iid myvar "somevalue"
Bernd> Q2: Should I use the IMPLIED keyword if the dwzProcName
Bernd> instances are of variable length ?
The rules on how to encode variable length strings in an instance
identifier are usually mis-understood. RFC 1212 says:
> (2) string-valued, fixed-length strings: `n' sub-identifiers,
> where `n' is the length of the string (each octet of the
> string is encoded in a separate sub-identifier);
>
> (3) string-valued, variable-length strings: `n+1' sub-
> identifiers, where `n' is the length of the string (the
> first sub-identifier is `n' itself, following this, each
> octet of the string is encoded in a separate sub-
> identifier);
This means that you have to use code similar to:
set iid [string length "myproc"]:[mib scan $dwzProcName "myproc"]
$session instance dwzProcName.$iid myvar "somevalue"
It is a fact that many implementations don't get this right.
RFC 1902 defines the same rules. However, it introduces the IMPLIED
keyword which allows to skip the length sub-identifier if the length
of the string can be determined by the length of the instance
identifier. In RFC 1902 words:
> Note that the IMPLIED keyword can only be present for an object
> having a variable-length syntax (e.g., variable-length strings or
> object identifier-valued objects), Further, the IMPLIED keyword can
> only be associated with the last object in the INDEX clause.
> Finally, the IMPLIED keyword may not be used on a variable-length
> string object if that string might have a value of zero-length.
The reason for introducing IMPLIED was to "legalize" implementations
that are broken according to RFC 1212. The problem is that you can't
convert a SNMPv2 MIB to a SNMPv1 MIB if you use the IMPLIED keyword
because SNMPv1 does not define the implied encoding (there are only
broken implementation).
Sorry for the long answer to this simple question,
Juergen
-- Juergen Schoenwaelder schoenw@cs.utwente.nl http://www.cs.utwente.nl/~schoenw Computer Science Department, University of Twente, (Fax: +31-53-489-3247) P.O. Box 217, NL-7500 AE Enschede, The Netherlands. (Tel. +31-53-489-3678)-- !! This message is brought to you via the `tkined & scotty' mailing list. !! Please do not reply to this message to unsubscribe. To subscribe or !! unsubscribe, send a mail message to <tkined-request@ibr.cs.tu-bs.de>. !! See http://wwwsnmp.cs.utwente.nl/~schoenw/scotty/ for more information.