usmStatsNotInTimeWindows issues
Thomas Anders
when using 5.1.2.pre2 as a client against a 5.0.9 agent on Linux (Debian Woody),
I recently ran into two (possibly related) problems:
1. The agent (uptime 268 days) suddenly started to answer all (previously
working) SNMPv3 authPriv requests with a SNMP REPORT indicating an
usmStatsNotInTimeWindows error, even if we use latest 5.1.2.pre2 as the client.
Does this ring a bell with anyone? USM engine time is ~21.700.000, currently.
Did I cross a magic boundary?
2. The 5.1.2.pre2 command-line tools (e.g. snmpget) handle this situation
quite badly: after sending the request seven times (and getting the REPORT
response each time), they hang in select() forever :(
The agent responses *do* arrive at the client (as "snmpget -Ddump" shows).
Restarting the agent will possibly fix the first issue (as it did for an agent
on another machine) and hide the second, but I'd really prefer to track this
down instead. Consequently, I can only turn on "-Dtoken" debugging on the
client, not on the agent.
Suggestions are highly appreciated.
+Thomas
--
Thomas Anders (thomas.anders at blue-cable.de)
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Net-snmp-coders mailing list
Net-snm...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
Martin Carlsson
5.0.8 and probably still in 5.1.x).
We came across a similar problem when setting the
clock with NTP for our boxes that lack a battery backed clock.
They start up in 1970 and suddenly (back to the future)
they are in 2004. Looking at the code there also seemed
to be an overflow problem occuring after 248 days and some tests
seemed to verify this. Both large time changes and the 248 days
overflow causes the agent to get stuck in "notInTimeWindow"-mode.
It is all related to the fact that the engineTime is calculated
with gettimeofday and in centiseconds. It is then stored in a
signed (normally 32 bit) integer. On most platforms this value
overflows after 2^31/100 seconds = 248,5 days.
There was an earlier discussion on this subject
in april. There is a fix for the problem (by me), use at own risk!
It prolongs the timespan to ~68 years and fixes the time change
problem. Only tested on Linux however.
If you look in the archives you should be able to find the earlier
discussion, subject was "engineTime and abrupt timechanges".
Cheers,
M
---
Martin Carlsson, martin dot carlsson at lumentis dot se
Lumentis AB, Jakobsdalsvagen 17, SE-126 53 Hagersten, Sweden
+46 (0)8 52 76 75 66, Fax: +46 (0)8 52 76 75 99
Thomas Anders
Martin> 5.0.8 and probably still in 5.1.x). [...]
Martin> Looking at the code there also seemed
Martin> to be an overflow problem occuring after 248 days and some tests
Martin> seemed to verify this. Both large time changes and the 248 days
Martin> overflow causes the agent to get stuck in "notInTimeWindow"-mode.
Thanks for the pointer. The former discussion ended up in
http://sf.net/mailarchive/forum.php?thread_id=4464869&forum_id=7152
with no indication of what branches this patch has been applied to.
Looking at 5.1.2.pre2's snmplib/snmpv3.c I still see the old code,
implying that any SNMPv3 agent based on a released Net-SNMP version
will stop working after ~248 days (for SNMPv3)!!? Am I missing something?
As this would qualify as a (serious) bug to me, can the patch be applied
to all branches, ASAP, please?
Thomas> 2. The 5.1.2.pre2 command-line tools (e.g. snmpget) handle this situation
Thomas> quite badly: after sending the request seven times (and getting the REPORT
Thomas> response each time), they hang in select() forever :(
Here's the last output from "snmpget -Dall ..." before the client gets
stuck in select():
dumpv_recv: ObjID: SNMP-USER-BASED-SM-MIB::usmStatsNotInTimeWindows.0
trace: snmp_pdu_parse(): snmp_api.c, 4257:
dumph_recv: Value
dumpx_recv: 41 02 04 77
dumpv_recv: UInteger: 1143 (0x477)
trace: _snmp_parse(): snmp_api.c, 3983:
snmp_parse: Parsed SNMPv3 message (secName:xxxxxx, secLevel:authNoPriv):
trace: snmpv3_get_report_type(): snmp_api.c, 3879:
report: Report type: -36
trace: snmp_sess_select_info(): snmp_api.c, 5621:
sess_select: for all sessions: 3
Thomas Anders
> Here's the last output from "snmpget -Dall ..." before the client gets
> stuck in select():
>
> dumpv_recv: ObjID:
> SNMP-USER-BASED-SM-MIB::usmStatsNotInTimeWindows.0
> trace: snmp_pdu_parse(): snmp_api.c, 4257:
> dumph_recv: Value
> dumpx_recv: 41 02 04 77
> dumpv_recv: UInteger: 1143 (0x477)
> trace: _snmp_parse(): snmp_api.c, 3983:
> snmp_parse: Parsed SNMPv3 message (secName:xxxxxx, secLevel:authNoPriv):
> trace: snmpv3_get_report_type(): snmp_api.c, 3879:
> report: Report type: -36
> trace: snmp_sess_select_info(): snmp_api.c, 5621:
> sess_select: for all sessions: 3
snmpget from CVS MAIN gets stuck in select(), too, and prints:
dumpv_recv: ObjID: SNMP-USER-BASED-SM-MIB::usmStatsNotInTimeWindows.0
trace: snmp_pdu_parse(): snmp_api.c, 4363:
dumph_recv: Value
dumpx_recv: 41 02 04 8C
dumpv_recv: UInteger: 1164 (0x48C)
trace: _snmp_parse(): snmp_api.c, 4089:
snmp_parse: Parsed SNMPv3 message (secName:xxxxxx, secLevel:authNoPriv):
trace: snmpv3_get_report_type(): snmp_api.c, 3977:
report: Report type: -36
trace: snmp_sess_select_info(): snmp_api.c, 5726:
sess_select: for all sessions: 3
sess_select: blocking:no session requests or alarms.
BTW, shouldn't snmplib/snmp_version.c in CVS MAIN now have
const char *NetSnmpVersionInfo = "5.2";
instead of "5.1"?
Robert Story (Coders)
TA> Thomas Anders wrote:
TA> BTW, shouldn't snmplib/snmp_version.c in CVS MAIN now have
TA>
TA> const char *NetSnmpVersionInfo = "5.2";
TA>
TA> instead of "5.1"?
You'd think so, wouldn't you? I'd actually prefer something that indicated cvs,
too: "5.2.0-cvs", or "pre-5.2.0-cvs".
The other developers don't agree with us. The policy seems to be that the
version numbers only change after a release.
--
Robert Story; NET-SNMP Junkie <http://www.net-snmp.org/>
<irc://irc.freenode.net/#net-snmp>
Archive: <http://sourceforge.net/mailarchive/forum.php?forum=net-snmp-coders>
You are lost in a twisty maze of little standards, all different.
Dave Shield
Thomas> BTW, shouldn't snmplib/snmp_version.c in CVS MAIN now have
Thomas> const char *NetSnmpVersionInfo = "5.2";
Robert> I'd actually prefer something that indicated cvs,
Robert> too: "5.2.0-cvs", or "pre-5.2.0-cvs".
Robert> The other developers don't agree with us.
I'm not quite sure where you got that idea from, Robert.
I'd also prefer to see an indication that this is a CVS-based version
of the code.
Dave
Niels Baggesen
> I'm not quite sure where you got that idea from, Robert.
> I'd also prefer to see an indication that this is a CVS-based version
> of the code.
I fully agree. The first thing I do after running cvs update is to patch
snmp_version to say 5.1.2.pre2+yyyy-mm-dd
/Niels
--=20
Niels Baggesen - @home - =C5rhus - Denmark - n...@users.sourceforge.net
The purpose of computing is insight, not numbers --- R W Hamming