> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
> Behalf Of Manfred Wassmann
> Sent: Monday, January 21, 2008 2:52 PM
> TNX for your answer. I actually have at least two instances
> of myVersion
> but they have to have different access clauses, so I guess I
> can't put
> them into one table. I rewrote my MIB to define myVersionDigits and
> myVersionState as seperate entities and it works so far. Yet
> I wonder why
> I can't combine them into a third entity like it is done in the
> UCD-SNMP-MIB:
>
> logMatchEntry OBJECT-TYPE
> SYNTAX LogMatchEntry
> [...]
> LogMatchEntry ::=
> SEQUENCE {
> logMatchIndex
> Integer32,
> [...]
Also, and importantly (as I understand it):
<SNIP>
logMatchTable OBJECT-TYPE
SYNTAX SEQUENCE OF LogMatchEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Table of monitored files."
::= { logMatch 2 }
</SNIP>
...which tells us that LogMatchEntry is a table row and may therefore
be a sequence. To elaborate on Dave's earlier point, SNMP's SMI is not a full
implementation of ASN.1. Only table rows may be SEQUENCEs.
> This is accepted by smilint but when I try the following smilint tells
> me: "MY-MIB.txt:91: [2] type `MyCompoundVersion' of node
> `myVersionNumber' does not resolve to a known base type"
Correct. You defined it as a SEQUENCE. It is not a table row, so
therefore must be a base type.
For a suggestion on how to solve your problem, check this from
SNMPv2-TC:
<SNIP>
TDomain ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Denotes a kind of transport service.
Some possible values, such as snmpUDPDomain, are defined in
the SNMPv2-TM MIB module. Other possible values are defined
in other MIB modules."
REFERENCE "The SNMPv2-TM MIB module is defined in RFC 1906."
SYNTAX OBJECT IDENTIFIER
TAddress ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Denotes a transport service address.
A TAddress value is always interpreted within the context of a
TDomain value. Thus, each definition of a TDomain value must
be accompanied by a definition of a textual convention for use
with that TDomain. Some possible textual conventions, such as
SnmpUDPAddress for snmpUDPDomain, are defined in the SNMPv2-TM
MIB module. Other possible textual conventions are defined in
other MIB modules."
REFERENCE "The SNMPv2-TM MIB module is defined in RFC 1906."
SYNTAX OCTET STRING (SIZE (1..255))
</SNIP>
These two objects are interlocked only by their definition - there is
no way to enforce this in SMI. MIBsmiths who wish to use this TC define
objects of both types, one after the other, either as scalars or as columnar
objects, depending on their need.
HTH,
Mike
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Net-snmp-users mailing list
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
