Re: snmptrapd - unable to receive informs

On 28 June 2011 20:28, Joan Landry <[email protected]> wrote:
> It fails if (ISENGINEKNOWN(secEngineID, *secEngineIDLen) == FALSE)
>
> Even though the engine id is correct (it is the engine id of the snmpd server).

Ah!  That might start to explain things

If you are working with unacknowledged SNMPv3 traps, then the authoritative
engine ID (as used in the PDU) is the engine ID of the *sender* (i.e. snmpd)
But with SNMPv3 _inform_ notifications, the authoritative engine ID is that
of the notification *receiver*  (i.e. snmptrapd)


> So it as if snmptrapd does not know its own engine id when processing an incoming inform packet.

But you've just said that it's using the engine ID of snmpd.
So things are *not* using it's  [snmptrapd's] own engine ID
(although they should be).

That's why I suggested removing the explicit engineID from the trapsess line,
to force snmpd to probe for it.

An alternative approach is to pick an engine ID, and specify this
explicitly for *both*
the trapsess line (in snmpd.conf) *and* the createUser line (in snmptrapd.conf).
That way, both sides of the conversation are using the same engine ID,
and things
should work OK.

Dave

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
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