On 16 October 2012 14:10, Giuseppe Modugno wrote:
> In this case, why to use the "service object" somethingChangedOID? The
> OID of the changed instance can be retrieved from the "extra" (not
> specified in the MIB) varbind that contains the value too, so the
> OBJECTS clause for the notification
Il 16/10/2012 09:56, Dave Shield ha scritto:
> Remember that you can always append additional varbinds to a
> notification payload - over and above those listed in the MIB definitions.
> So as well as the
> somethingChangedOID.0 = theOidThatChanged
>
> varbind, the notification could also con
On 16 October 2012 09:05, Giuseppe Modugno wrote:
>> Remember that you can always append additional varbinds to a
>> notification payload - over and above those listed in the MIB definitions.
> Really? I thought I was forced to append just the varbinds defined in
> the MIB. Which is the RFC wher
Il 16/10/2012 09:56, Dave Shield ha scritto:
> On 16 October 2012 08:32, Giuseppe Modugno wrote:
>> Now I'd like to have an agent that sends a notification for *each*
>> parameter: if an alarm occurs, if the user change a setting (even
>> through SNMP SET) and so on.
>>
>> The only approach I know
On 16 October 2012 08:32, Giuseppe Modugno wrote:
> Now I'd like to have an agent that sends a notification for *each*
> parameter: if an alarm occurs, if the user change a setting (even
> through SNMP SET) and so on.
>
> The only approach I know is to define in the MIB a different
> NOTIFICATION-
I created a private MIB with many parameters. Some of them are read-only
(they represent the status of the machine), other are read-write (user
settings) parameters. I defined some notifications for very important
events: alarms, change of core settings and so on.
Now I'd like to have an agent
