On Tue, Dec 4, 2012 at 5:06 AM, <[email protected]> wrote:
> Thank you for your input.
>
> You say there is no such thing as text enumeration, but what of the
> following from SMIv2 RFC:
> SimpleSyntax ::=
> CHOICE {
> number
> INTEGER,
> string
> OCTET STRING,
> object
> OBJECT IDENTIFIER,
> empty
> NULL
> }
>
> Could this be used to make a string enumeration syntax?
> Something like: CHOICE { text1 OCTET STRING, text2 OCTET STRING, text3
> OCTEC STRING }
> I know this doesn't work because the validator (smilint) is complaining.
>
No you can't. A 'choice' is equivalent to a C union, in order to define
that 'different constructs can follow here'. Ie. a different kind of
'thing'
follows, not a different 'value' of a thing.
Regarding the OPAQUE DOUBLE. Looks like if I want to give the user the
> complete value I would have to use OCTET STRING for doubles.
>
OPAQUE (or OPAQUE anything) is used so that you can encode anything
you want (based on the predefined (BER) types)
The trouble is that the definition will be only between you and yourself.
The selection of OPAQUE DOUBLE may work for you, but it is still,
effectively,
a non-standard and I don't think you can expect any management system
to support that data type 'out of the box'.
An extract from the book "Understanding SNMP MIBs" by Perkins/McGinnis
(a book I highly recommend!) gives the following examples:
-- The textual convention for an Opaque based single precision floating
point
Float ::= Opaque (SIZE(...)) -- important details left out
voltageLevel OBJECT-TYPE
SYNTAX Float
UNITS "volts"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The current output level expressed in volts."
::= { voltage 1}
-- The textual convention for an Opaque based double precision floating
point
Double ::= Opaque (SIZE(...)) -- important details left out
voltageLevel OBJECT-TYPE
SYNTAX Double
UNITS "volts"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The current output level expressed in volts."
::= { voltage 1}
> /Sverre
>
> Siterer "Fulko Hew" <[email protected]>:
>
> On Mon, Dec 3, 2012 at 6:51 AM, <[email protected]> wrote:
>>
>> I must ask, is this mailing list dead for some reason, or is people
>>> just very busy? Or perhaps I have been nagging the mailing list so
>>> many times with questions.
>>>
>>>
>>
>> No, its probably because if nobody knows the right answer (for sure)
>> they will probably not answer. But let me give you what I know.
>>
>>
>>
>> My SNMP AgentX application is nearly complete, but I need help to
>>> answer some standing questions that I'm struggling with.
>>>
>>> I would appreciate it very much if anyone could answer the following
>>> emails I sent to the mailing list.
>>> * Textual enumeration in MIB (this is actually more of a SMIv2 problem
>>> than SNMP)
>>>
>>>
>> There is no such thing as an enumeration represented as text.
>> They are always integers. The name equivalent you assign to the number
>> is for the benefit of somebody's source code or for the display on an NMS.
>>
>> So what you have to have is:
>>
>> param2 OBJECT-TYPE
>> SYNTAX INTEGER { stopped (0), ready (1), running(2) }
>>
>>
>> * Choosing the right ASN type
>>
>>>
>>>
>> Here you asked two questions:
>>
>> unfortunately, the agents I've been writing have been AgentX (using my
>> Perl
>> and/or Java
>> sub-agent library, but...
>>
>> 1/ about integer32, I'd say use ASN_UNSIGNED, from my poor memory...
>>
>> I don't have my reference information in front of me, but the differences
>> are:
>> - numbers from -2 gig to +2 gig
>> - numbers from 0 to 4 gig
>> - a things that are only allowed to 'increase'
>>
>> 2/ and the whole business of OPAQUE or float is true.
>>
>> I don't believe there is a _real_ standard for floats, and OPAQUE is a way
>> to encode 'other stuff', but you can't count on it being usable anywhere
>> else, but in your code. Where ever I have needed something code
>> to a float, I redefine it as an integer to avoid the problem. I.e Instead
>> of saying 3.5 seconds, I use 3500 milliseconds.
>>
>>
>> In addition I am wondering about the agent mode MODE_SET_BEGIN. When
>>
>>> issuing an snmpset this mode is never entered into. It would be great
>>> to have such a mode available. When I issue an snmpset with multiple
>>> OIDs, I would like the handler to do some initial work only once
>>> before SET_RESERVER1, SET_RESERVER2, SET_ACTION on the various OIDs in
>>> the request.
>>>
>>>
>> And since I can't speak intelligently about this... I won't.
>>
>>
>
>
------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
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
