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

List:       net-snmp-bugs
Subject:    [ net-snmp-Bugs-903171 ] SNMP.pm sometimes mangles engine time?
From:       "SourceForge.net" <noreply () sourceforge ! net>
Date:       2004-02-25 0:13:31
Message-ID: E1Avmg7-0005m1-00 () sc8-sf-web3 ! sourceforge ! net
[Download RAW message or body]

Bugs item #903171, was opened at 2004-02-23 18:12
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112694&aid=903171&group_id=12694

Category: library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: SNMP.pm sometimes mangles engine time?

Initial Comment:
In Cricket 1.0.4 using the supplied alternate
snmpUtils.pm (which uses SNMP.pm) for v3 support, I
notice that for some hosts, all requests are errored by
the agent with notInWindow indication.  The same
requests, when made through a C client (like
snmpget(1)) work correctly.

An examination of the traffic shows that the requests
are being sent with a bogus engine time:

20:40:52.586034 cheyenne-mountain.csail.mit.edu.55207 >
loop.kalgan.csail.mit.edu.snmp: { SNMPv3 { F=r } { USM
B=0 T=0 U= } { ScopedPDU E=  C= { GetRequest(14)
R=1006035020 } } }  (ttl 64, id 35714, len 92)
20:40:52.586776 loop.kalgan.csail.mit.edu.snmp >
cheyenne-mountain.csail.mit.edu.55207: { SNMPv3 { F= }
{ USM B=1 T=282506 U= } { ScopedPDU E=
0x800x000x000x090x030x000x000x000x150x000x000x00 C= {
Report(32) R=1006035020 
S:snmpUsmMIB.usmMIBObjects.usmStats.usmStatsUnknownEngineIDs.0=954}
} }  (ttl 254, id 18607, len 135)
20:40:52.587482 cheyenne-mountain.csail.mit.edu.55207 >
loop.kalgan.csail.mit.edu.snmp: { SNMPv3 { F=ar } { USM
B=1 T=2178740 U=admin } { ScopedPDU E=
0x800x000x000x090x030x000x000x000x150x000x000x00 C= {
GetRequest(28) R=1006035021  system.sysUpTime.0} } } 
(ttl 64, id 35715, len 149)

Note how it sends one packet with B=0, T=0 per the
protocol, gets a response that says T=282506, and then
sends its request with B=1 T=2178740 (where did that
come from?!).

-GAWollman
wollman@lcs.mit.edu


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

Comment By: Nobody/Anonymous (nobody)
Date: 2004-02-24 16:13

Message:
Logged In: NO 

It's difficult to tell.  The cricket collector doesn't run
continuously, but it does successfully communicate with a
number of v1 and v3 agents both before and after failing
with the problem hosts.  (The version of Perl, FWIW, is 5.8
and net-snmp is 5.1 [behavior unchanged in 5.1.1.pre1].)
I can make a tcpdump capture of cricket's activity available
if it would help.

The shipping alternate snmpUtils.pm attempts to maintain a
LRU cache of SNMP sessions.  I have disabled that feature in
my version to assist in debugging (with no change in
behavior).

-GAWollman


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

Comment By: Wes Hardaker (hardaker)
Date: 2004-02-24 06:25

Message:
Logged In: YES 
user_id=76242

Does that happen for continuesly running scripts only?  Or does perl 
mess up when recently started as well?  Does it mess up consisently 
for one host? 

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

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


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
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]