On 28 June 2011 20:28, Joan Landry <joan.lan...@overturenetworks.com> 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 Net-snmp-users@lists.sourceforge.net Please see the following page to unsubscribe or change other options: https://lists.sourceforge.net/lists/listinfo/net-snmp-users
