More Documentation on Possible Net-SNMP SNMP v3 Trap Bug

As I mentioned in an update to this post, I think my inability to send SNMP v3 traps is a bug in Net-SNMP and not operator error. I'll know for sure when Net-SNMP 5.2.4 arrives. Prior to that I might download source and apply the patch.

For my own reference I decided to split the sending and reception of the trap. In this example, host orr is sending the trap and host hacom is receiving.

Here's orr's /usr/local/etc/snmp/snmpd.conf

rocommunity     read
rwcommunity     write

rwuser  richard  priv

createUser             richard MD5 bejtlichpass DES bejtlichpass
createUser              myuser MD5 mypassword DES myotherpassword
createUser              doit MD5 doitpassword DES doitpassword

I start snmpd on orr:

orr:/root# snmpd -f -Lo -Dusm
mibII/mta_sendmail.c:open_sendmailst: could not guess version of statistics file "/var/log/sendmail.st"
usmUser: created a new user richard at 80 00 1F 88 80 1E 52 61 18 B4 C7 F9 44 
usmUser: created a new user myuser at 80 00 1F 88 80 1E 52 61 18 B4 C7 F9 44 
usmUser: created a new user doit at 80 00 1F 88 80 1E 52 61 18 B4 C7 F9 44 
NET-SNMP version 5.2.3

Here's hacom's /usr/local/etc/snmp/snmptrapd.conf:

createUser -e 0x80001F88802DE1801D35C4F944 doit MD5 doitpassword DES doitpassword

I start snmptrapd on hacom (192.168.2.18):

hacom:/root# snmptrapd -Dusm -f -Lo
usmUser: created a new user doit at 80 00 1F 88 80 2D E1 80 1D 35 C4 F9 44 
2006-09-02 14:08:41 NET-SNMP version 5.2.2 Started.

I try to send a trap from orr to hacom:

orr:/home/richard$ snmptrap -Ddumph_send,dumpv_send,usm -v 3
 -e 0x80001F88802DE1801D35C4F944 -u doit -a MD5 -A doitpassword -l authNoPriv 
 192.168.2.18 '' SNMPv2-SMI::enterprises.3.1.1
dumph_send: SNMPv3 Message
dumph_send:   TRAP2
dumph_send:     VarBind
dumph_send:       Value    ObjID: SNMPv2-SMI::enterprises.3.1.1
dumph_send:       Name    ObjID: SNMPv2-MIB::snmpTrapOID.0
dumph_send:     VarBind
dumph_send:       Value    UInteger:    420340 (0x669F4)
dumph_send:       Name    ObjID: DISMAN-EVENT-MIB::sysUpTimeInstance
dumph_send:   error index    Integer:   0 (0x00)
dumph_send:   error status    Integer:  0 (0x00)
dumph_send:   request_id    Integer:    1567731639 (0x5D71AFB7)
dumph_send:   ScopedPdu
dumph_send:     contextName    String: [NULL]
dumph_send:     contextEngineID    String:      ......s5o...D
dumph_send: msgSecurityModel    Integer:        3 (0x03)
dumph_send: msgFlags    String: .
dumph_send: msgMaxSize    Integer:      65507 (0xFFE3)
dumph_send: msgID    Integer:   1089578781 (0x40F1A71D)
dumph_send: SNMP Version Number    Integer:     3 (0x03)
dumph_send: SM msgSecurityParameters
usm: USM processing has begun (offset 76)
usm: getting user doit
usm: Unknown User
snmptrap: USM unknown security name (no such user exists)

No workie. Host orr never even sends a packet and snmptrapd on host hacom never receives a packet. That indicates a bug in the snmptrap command as suspected here.

This is an old bug, but the patch has this comment:

Date: 2006-08-24 07:10
Sender: tanders
Logged In: YES 
user_id=848638

This patch has not been applied to the 5.2.x CVS tree before
today, so it also applies to 5.2.3. It'll be fixed in
5.2.4.