Hi,
Thanks for your explanation, Dave.
I have put in the name of the object (ie. The table element) that I want to be
returned with the notification resulting with the entry now being:
notificationVswr NOTIFICATION-TYPE
DESCRIPTION "High VSWR"
OBJECTS { radioVswr }
Status current
::= { notificationGroup 5 }
For completion, you are correct. Vswr is a term for the RF reflection ratio
that I am monitoring, and when it goes out of range, I would like to send a
notification with the current value.
However when the notification triggers, I get the following (as observed in
Wireshark):
SNMPv2-SMI::enterprises.33302.10.2.7.1.2.0
(1.3.6.1.4.1.33302.10.2.7.1.2.0): noSuchInstance
1.3.6.1.4.1.33302.10.2.7.1.2 is the OID of the field I want to retrieve in the
table. If I do an snmpget on the OID 1.3.6.1.4.1.33302.10.2.7.1.2.1 this
returns the correct field and element, the 1 being the index into the table (or
is it better to be referred to as the first instance?).
You mentioned that I am required to write code to generate the notification? So
far, I have only been modifying the MIB files to get traps to be fired. Is
there something I need to do so that the notification being sent sends the
correct OID-referenced object?
Thanks again for your assistance.
Wei
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of Dave Shield
Sent: Thursday, 2 February 2012 7:22 PM
To: Wei-Cheng Kong
Cc: [email protected]
Subject: Re: Including table elements in traps
On 2 February 2012 02:19, Wei-Cheng Kong <[email protected]> wrote:
> I am having some issues including table elements inside a trap notification.
> Can someone tell me what the format is for including a table element inside
> a NOTIFICATION-TYPE?
There's essentially no difference between define a trap that contains
scalar object, and one that contains table elements (or a mixture of
the two)
> I have the following in a MIB (extract):
> radioVswrEntry OBJECT-TYPE
> SYNTAX radioVswrEntry
:
> INDEX { radioVswrTableIndex }
> radioVswrEntry ::=
> SEQUENCE {
> radioVswrTableIndex INTEGER,
> radioVswr INTEGER
> }
So your table contains two MIB objects - the index
and one other column object.
> radioVswrTableIndex OBJECT-TYPE
> SYNTAX INTEGER
> ACCESS read-only
First thing - this object should be defined as "not-accessible"
> I am unsure what I should be putting inside the OBJECTS field
> within the NOTIFICATION-TYPE notificationVswr.
You list the name(s) of the MIB object(s) that you want to include.
> I have tried putting radioVswr.1 (the object I want to return)
No - that's an *instance* of this object.
The MIB definition should contain the name of the object itself:
> notificationVswr NOTIFICATION-TYPE
> DESCRIPTION "High VSWR
> OBJECTS { highVswr }
> Status current
> ::= { notificationGroup 5 }
This should be
OBJECTS { radioVswr }
(and
STATUS current )
> However, if I include the OID in the snmpd.conf instead of modifying
> the NOTIFICATION-TYPE with -i preceeding the OID, I get the object
> returned with the notification, which is the behaviour I am after.
> But this isn't as neat as having it all defined within the MIB.
Err... this feels to be talking about something slightly different.
The MIB file is concerned with *defining* the notification, describing
what examples of this notification should look like. That's separate
from providing code to *implement* this notification - i.e. actually
sending a trap that conforms to the definition.
Let's get the notification definition fixed first - then we can talk about
how you go about generating examples of it.
> Another question would be, is it possible to return all present rows in
> the table rather than explicitly specifying an individual OID for each row?
Errr... not really.
Remember that the notification is a way of the agent saying
"something has happened"
The description of notificationVswr is a little bit vague, but presumably
it refers to one of the radioVswr values going "out of range" in some way.
Now if the table contains several radioVswr instances, presumably these
are essentially independent.
If instance #2 goes skyrocketing, this won't affect the values of instance
#1, or #3ff. So the notification that gets generated would contain the
instance varbind radioVswr.2.
Similarly if instance #99 went out of range, the notification would contain
radioVswr.99. There's no point in including the whole table in the trap.
You're only interested in the particular row that triggered the event.
> I have a feeling a solution is related to preceeding the OID in the
> snmpd.conf with -o rather than -i. Hopefully there is a solution
> involving just the MIB file.
You still seem to be confusing the definition of the notification,
with how this is implemented. These are two distinct concepts,
and you should keep them separate in your mind.
Dave
------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
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
