[AGENT++] notification-log-mib questions

[Frank Fock]

Hi Claus,

I think I have found the bug regarding the filtering:

In line 1303 of notification_log_mib.cpp the first and second parameter 
(both of type Oidx) are interchanged.

Regarding the address field that is stored in the notification
log MIB, the reasoning of the RFC is questionable.

The RFC describes the notification logging from the perspective
of an entity that collects notification (receiver).

A AGENT++/SNMP4J agent receives the notifications through an internal
mechanism which replaces an external entity at the notification
sink. To be able to distinguish those sinks I log the target
addresses. Using the source address instead, would have violated
the requirement of the RFC to log the address from which the
notification had been received. Which is not the address/port
from the notification had been sent.

Can you follow that model?

Best regards,
Frank

On 10.09.2010 21:16, Claus Klein wrote:
> Hi Frank,
>
> there is an additional issue I found today while testing the
> snmpNotifyFilterTable:
>
> With a filter which excludes the trap OID, the trap is not added to the
> notificationLogTable, but it is send anyway?
>
> That is wrong according the http://tools.ietf.org/html/rfc3413#page-15
>
> (1) Any appropriate filtering mechanisms are applied to determine
>         whether the notification should be sent to the management target.
>         If such filtering mechanisms determine that the notification
>         should not be sent, processing continues with the next management
>         target.
>
> ...
>
>
> and http://tools.ietf.org/html/rfc3413#page-64
>
> Otherwise, if matching entries do exist, a notification may be sent
>     if the NOTIFICATION-TYPE OBJECT IDENTIFIER of the notification (this
>     is the value of the element of the variable bindings whose name is
>     snmpTrapOID.0, i.e., the second variable binding) is specifically
>     included, and none of the object instances to be included in the
>     variable-bindings of the notification are specifically excluded by
>     the matching entries.
>
> ...
>
>
> With best regards,
>
> Claus
>
>
> On 10.09.2010, at 00:54, Frank Fock wrote:
>
>> Hi Claus,
>>
>> If AGENT++ indeed logs the notifications like you wrote
>> below, then it is a bug and will be fixed in the next
>> release. I will check that.
>>
>> Best regards,
>> Frank
>>
>> On 09.09.2010 23:10, Claus Klein wrote:
>>> Hi everybody,
>>>
>>> while working with the agentx master demo I tested the notification-
>>> log-mib.
>>>
>>> First, I found, that an target address (IPv6) is not right handled!
>>> Only 4 bytes are used instead of 16?
>>>
>>> Second, for each notify target, an row is created at the nlmNotifyTable.
>>> There is no new information if each address from the
>>> targetAddressTable is stored at the nlmNotifyTable again.
>>> The RFC says, the the source Address should be stored, not the
>>> destination!
>>>
>>> What I expected was, that one notification which occurs at the snmp
>>> agent will be stored, independent of the count of targets to deliver
>>> it as traps or informs.
>>> In worst case, it will only stored, but not delivered (and has to be
>>> polled by NMS from the nlmNotifyTable)
>>>
>>> Only an snmptrapd (trap client) has to write the source address of the
>>> trap to distinguish the same trap from different agents.
>>> That is the way, net-snmp implements it.
>>>
>>>
>>> What is your opinion about that?
>>>
>>> Whit kind regards,
>>>
>>> Claus
>>> _______________________________________________
>>> AGENTPP mailing list
>>> AGENTPP at agentpp.org <mailto:AGENTPP at agentpp.org>
>>> http://lists.agentpp.org/mailman/listinfo/agentpp
>>
>> --
>> AGENT++
>> http://www.agentpp.com
>> http://www.snmp4j.com
>> http://www.mibexplorer.com
>> http://www.mibdesigner.com
>>
>> _______________________________________________
>> AGENTPP mailing list
>> AGENTPP at agentpp.org
>> http://lists.agentpp.org/mailman/listinfo/agentpp
>

-- 
AGENT++
http://www.agentpp.com
http://www.snmp4j.com
http://www.mibexplorer.com
http://www.mibdesigner.com