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
I start snmpd on orr:
Here's hacom's /usr/local/etc/snmp/snmptrapd.conf:
I start snmptrapd on hacom (192.168.2.18):
I try to send a trap from orr to hacom:
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:
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.
Comments