snmptrapd "USM not in time window" problem.

Hi,

My snmpd agent is v5.2.1 running on SunOS 5.8, and snmptrapd receiver is
v5.2.1 running on SuSE Linux 9.3.

What I'm doing is:
I'm using trapsess to send v3 trap, as well as I have 'extend' line in
snmpd.conf to call a perl script to send a string message using snmptrap in
some interval.

The problem is:
Whenever the perl script got called and snmptrap sent the message, the
snmptrapd couldn't interprete any of the system traps defined in snmpd.conf
anymore. I verified all the system traps and the message sent by snmptrap
went out from the snmpd machine, and also reached the destinate snmptrapd
receiver. But the snmptrapd.log didn't have them except for the message sent
by snmptrap.

Investigation I did:
I turned on the debug for snmptrapd by giving -DAll option, the output as
below:
1) successful trap received by snmptrapd:
--------------------------------------------------------------
....
race: sc_hash(): scapi.c, 414:
trace: sc_get_properlength(): scapi.c, 117:
trace: sc_hash(): scapi.c, 414:
trace: sc_get_properlength(): scapi.c, 117:
trace: set_enginetime(): lcd_time.c, 356:
lcd_set_enginetime: engineID 00 0E 0C 5B 64 7C 79 98
: boots=0, time=0
trace: usm_check_secLevel(): snmpusm.c, 2873:
comparex: Comparing: 1 3 SNMP-USER-BASED-SM-MIB::usmNoPrivProtocol
trace: sc_check_keyed_hash(): scapi.c, 535:
trace: sc_generate_keyed_hash(): scapi.c, 278:
trace: sc_get_properlength(): scapi.c, 117:
trace: usm_process_in_msg(): snmpusm.c, 2471:
usm: Verification succeeded.
trace: sc_hash(): scapi.c, 414:
trace: sc_get_properlength(): scapi.c, 117:
trace: get_enginetime_ex(): lcd_time.c, 250:
lcd_get_enginetime_ex: engineID 00 0E 0C 5B 64 7C 79 98

(COMPARE TO THE SAME PLACE BELOW)
: boots=0, time=0

trace: sc_hash(): scapi.c, 414:
trace: sc_get_properlength(): scapi.c, 117:
trace: set_enginetime(): lcd_time.c, 356:
lcd_set_enginetime: engineID 00 0E 0C 5B 64 7C 79 98
: boots=0, time=0
trace: sc_decrypt(): scapi.c, 910:
trace: usm_process_in_msg(): snmpusm.c, 2653:
usm: USM processing completed.
trace: snmpv3_parse(): snmp_api.c, 3770:
dumph_recv: * * ScopedPDU
trace: snmpv3_scopedPDU_parse(): snmp_api.c, 4468:
....

2) problem trap:
--------------------------------------------------------------
....
trace: sc_hash(): scapi.c, 415:
trace: sc_get_properlength(): scapi.c, 117:
trace: set_enginetime(): lcd_time.c, 356:
lcd_set_enginetime: engineID 00 07 E9 1B 0B D3 62 86
: boots=0, time=0
trace: usm_check_secLevel(): snmpusm.c, 2873:
comparex: Comparing: 1 3 SNMP-USER-BASED-SM-MIB::usmNoPrivProtocol
trace: sc_check_keyed_hash(): scapi.c, 539:
trace: sc_generate_keyed_hash(): scapi.c, 278:
trace: sc_get_properlength(): scapi.c, 117:
trace: usm_process_in_msg(): snmpusm.c, 2471:
usm: Verification succeeded.
trace: sc_hash(): scapi.c, 415:
trace: sc_get_properlength(): scapi.c, 117:
trace: get_enginetime_ex(): lcd_time.c, 250:
lcd_get_enginetime_ex: engineID 00 07 E9 1B 0B D3 62 86

(NOTE HERE)
: boots=1, time=18191802

trace: usm_check_and_update_timeliness(): snmpusm.c, 2159:
usm: Remote boot count invalid.
trace: snmpv3_parse(): snmp_api.c, 3745:
dumph_recv: * * * * * * * * * * * * * * * ScopedPDU
trace: _snmp_parse(): snmp_api.c, 4091:

(PROBLEM LINE: I guess)
snmp_parse: Parsed SNMPv3 message (secName:cczhao, secLevel:authPriv): USM
not
in time window

trace: _sess_process_packet(): snmp_api.c, 5025:
sess_process_packet: parse fail
trace: _sess_read(): snmp_api.c, 5291:
sess_read: not reading 5 (fdset 0xbfffee40 set 0)
trace: _sess_read(): snmp_api.c, 5291:
sess_read: not reading 3 (fdset 0xbfffee40 set 0)
trace: snmp_sess_select_info(): snmp_api.c, 5702:
sess_select: for all sessions: 9 5 3
sess_select: next alarm 8.605901 sec
verbose:sess_select: timer due in 8.605901 sec
trace: netsnmp_udp_recv(): snmpUDPDomain.c, 134:
netsnmp_udp: recvfrom fd 9 got 175 bytes (from UDP: [10.1.4.10]:25304)
trace: _sess_process_packet(): snmp_api.c, 4973:
sess_process_packet: session 0x80924f0 fd 9 pkt 0x80973e8 length 175
....

Then, I went to the source code, I found:
the function search_enginetime_list() in snmplib/lcd_time.c searchs hash
table
to see if the engineID is there. So this makes me think the snmptrapd cached
the engineID (with a time?) from where the last trap (sent by snmptrap)
comes
in; and when the next trap (sent by snmpd) comes in, it detects the time
won't match or whatever, it then refuses it. Am I right?

Also, because the comment says:
* ASSUMES that no engineID will have more than one record in the list.

I checked snmptrapd.conf in the persistance directory, I did see couple
duplicated lines. Is this the reason?

I'm so sorry for the long post, but I just want to describe the problem as
clear as possible. So, could any one here please point me out how I can fix
this problem?

Thank you very much.

--
Changchun
czhao@nextone.com




-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
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/...net-snmp-users