Summary
When opctrapi is configured with NO_TRAPD to process the trap, the enterprise ID as .1.3.6.1.4.1.11.5.7.5.1 rather than .1.3.6.1.6.3.1.1.5. Why is this?
Question
When opctrapi is configured with NO_TRAPD to process the trap, the enterprise ID as .1.3.6.1.4.1.11.5.7.5.1 rather than .1.3.6.1.6.3.1.1.5. Why is this?
Sending in a test SNMP event:
snmptrap -v 2c -c public server.com "" .1.3.6.1.6.3.1.1.5.3 .1.3.6.1.2.1.2.2.1.1.1001 integer 1001 .1.3.6.1.2.1.2.2.1.7.1001 integer 1
.1.3.6.1.2.1.2.2.1.8.1001 integer 2 .1.3.6.1.6.3.1.1.4.3.0 oid 1.3.6.1.4.1.11.5.7.5.1
NETSNMP formatted event:
Generic: 2; Specific: 0; Community: public; Enterprise: .1.3.6.1.6.3.1.1.5;
Variables:
[1] .1.3.6.1.2.1.2.2.1.1.1001 (Integer): 1001
[2] .1.3.6.1.2.1.2.2.1.7.1001 (Integer): 1
[3] .1.3.6.1.2.1.2.2.1.8.1001 (Integer): 2
[4] .1.3.6.1.6.3.1.1.4.3.0 (ObjectIdentifier): .1.3.6.1.4.1.11.5.7.5.1
NO_TRAPD formatted event:
Generic: 2; Specific: 0; Community: public; Enterprise: .1.3.6.1.4.1.11.5.7.5.1;
Variables:
[1] .1.3.6.1.2.1.2.2.1.1.1001 (Integer): 1001
[2] .1.3.6.1.2.1.2.2.1.7.1001 (Integer): 1
[3] .1.3.6.1.2.1.2.2.1.8.1001 (Integer): 2
Why does NO_TRAPD show enterprise ID as .1.3.6.1.4.1.11.5.7.5.1 rather than .1.3.6.1.6.3.1.1.5
Answer
The problem you are seeing here is the differences in the handling of the SNMP trap between the net-snmp code (NETSNMP) and old NNM 7.x snmp code (NO_TRAPD).
The former is clearly just passing the trap details through as they are, however the NNM code is trying to be a little more helpful and is identifying the last varbind as the snmpEnterprise MIB variable which contains the trap Enterprise. So it is replacing the enterprise value in the SNMP PDU header with the value that is in the varbind – which is why the varbind is there.
When you remove this varbind then the two sets of code will operate in the same way as you have removed the override information.