[prev in list] [next in list] [prev in thread] [next in thread] 

List:       net-snmp-bugs
Subject:    [ net-snmp-Bugs-3555698 ] snmptrapd does not recognise changed AuthoritativeEngineTime
From:       SourceForge.net <noreply () sourceforge ! net>
Date:       2012-08-14 16:14:24
Message-ID: E1T1JlB-0008DY-O7 () sfs-ml-4 ! v29 ! ch3 ! sourceforge ! com
[Download RAW message or body]

Bugs item #3555698, was opened at 2012-08-09 06:45
Message generated for change (Comment added) made by tanders
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112694&aid=3555698&group_id=12694

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: snmptrapd
Group: linux
> Status: Closed
> Resolution: Invalid
Priority: 5
Private: No
Submitted By: Martin (martinxen)
Assigned to: Nobody/Anonymous (nobody)
Summary: snmptrapd does not recognise changed AuthoritativeEngineTime

Initial Comment:
steps to reproduce this issue:
- configure snmptrapd to receive SNMPv3 traps
- send a SNMPv3 trap to snmptrapd
- instruct the sender (a router) to reboot and send this trap again


result:
- the first trap will be received and logged correctly (msgAuthoritativeEngineTime = \
                155)
- if the second trap is received, snmptrapd will not log this trap because the \
                \'msgAuthoritativeEngineTime\' is now smaller as the one from the \
                first trap
- now the mesage \'message (secName:TrapuserV3, secLevel:authPriv): USM not in time \
window\' appears

If the uptime from my DUT (a router) is bigger than the AuthoritativeEngineTime from \
the first trap, snmptrapd will receive all traps correctly again.

Please fixe this issue, because the sender engine time can be smaller or bigger as \
the current saved sender engine time in any snmptrapd states (identified by \
EngineID).


----------------------------------------------------------------------

> Comment By: Thomas Anders (tanders)
Date: 2012-08-14 09:14

Message:
Closing this bug because the net-snmp behaviour looks correct.

----------------------------------------------------------------------

Comment By: Bill Fenner (fenner)
Date: 2012-08-14 05:19

Message:
Yes, msgAuthoritativeEngineBoots increments on every boot, and can reset to
zero when you change the engineID (not any other change, though). There are
also plenty of rules in RFC3414 about reaching the max value of
msgAuthoritativeEngineBoots, etc.

----------------------------------------------------------------------

Comment By: Martin (martinxen)
Date: 2012-08-13 05:20

Message:
No, msgAuthoritativeEngineBoots is alway set to '1'.

I see in your traces that 'your' msgAuthoritativeEngineBoots is
incremented. (And I read the RFC3414 :-) )
Does this mean that the SNMP-engine has always to increment this counter
each time the SNMP engine gets re-initializied/booted?
And at the other way: This value is set to '0' if the configuration of the
snmp engine gets changed?











----------------------------------------------------------------------

Comment By: Bill Fenner (fenner)
Date: 2012-08-10 07:21

Message:
This works for me.  Is your DUT incrementing msgAuthoritativeEngineBoots
when it reboots?

Before rebooting:


trace: usm_parse_security_parameters(): snmpusm.c, 1957:
dumph_recv:     msgAuthoritativeEngineBoots
dumpx_recv:      02 01 02
dumpv_recv:        Integer:     2 (0x02)
trace: usm_parse_security_parameters(): snmpusm.c, 1981:
dumph_recv:     msgAuthoritativeEngineTime
dumpx_recv:      02 02 02 8A
dumpv_recv:        Integer:     650 (0x28A)
...

2012-08-10 07:13:04 <UNKNOWN> (UDP:
[172.17.5.149]:45927->[172.17.21.4]:162) TRAP2, SNMP v3, user trappy,
context
 SNMPv2-MIB::sysUpTime.0 = Timeticks: (65029) 0:10:50.29
 SNMPv2-MIB::snmpTrapOID.0 = OID: SNMPv2-SMI::enterprises.30065.3.3.0.0.1
 SNMPv2-SMI::enterprises.30065.3.3.1.1.0 = Gauge32: 10
 SNMPv2-SMI::enterprises.30065.3.3.1.2.0 = STRING: "Hello, World"

After rebooting:

...


trace: usm_parse_security_parameters(): snmpusm.c, 1957:
dumph_recv:         msgAuthoritativeEngineBoots
dumpx_recv:          02 01 05
dumpv_recv:            Integer: 5 (0x05)
trace: usm_parse_security_parameters(): snmpusm.c, 1981:
dumph_recv:         msgAuthoritativeEngineTime
dumpx_recv:          02 02 00 FE
dumpv_recv:            Integer: 254 (0xFE)
...

2012-08-10 07:20:32 <UNKNOWN> (UDP:
[172.17.5.149]:56573->[172.17.21.4]:162) TRAP2, SNMP v3, user trappy,
context
 SNMPv2-MIB::sysUpTime.0 = Timeticks: (25444) 0:04:14.44
 SNMPv2-MIB::snmpTrapOID.0 = OID: SNMPv2-SMI::enterprises.30065.3.3.0.0.1
 SNMPv2-SMI::enterprises.30065.3.3.1.1.0 = Gauge32: 2
 SNMPv2-SMI::enterprises.30065.3.3.1.2.0 = STRING: "After reboot"


----------------------------------------------------------------------

Comment By: Martin (martinxen)
Date: 2012-08-09 07:06

Message:
used net-snmp version:  5.7.1

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112694&aid=3555698&group_id=12694

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Net-snmp-bugs mailing list
Net-snmp-bugs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-bugs


[prev in list] [next in list] [prev in thread] [next in thread]