Re: Including table elements in traps

[Dave S. <D.T...@li...>]

On 2 February 2012 02:19, Wei-Cheng Kong <wei...@tr...> 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