Re: Peculiar behaviour with snmp get - scotty 2.0.2

Michele Chen (michele@pqtech.com)
Tue, 10 Sep 96 14:24:26 PDT

Thanks for the quick response Juergen. Unfortunately, due to dependencies
on itcl and other extensions, I can't yet move to tcl7.5 and tk4.1. However,
as you requested, I've provided a sample script that demonstrates the problem (at
least at my site). My code does a lot of processing, so I had to send out a LOT more
requests in this sample to demonstrate the problem, but you should see it.

My initial problem report contained a mistake, in that timeouts and retries seem to
not only influence, but trigger the problem. If I bump the timeout interval to 60
seconds for example, I don't see the problem, or at least the problem does not show
up as rapidly.

Here's the code. Change the IP address to any device that supports MIB-II and see what
happens.

Thanks,

Michele

===============================================================
Michele Chen PQ Technologies, Inc.
michele@pqtech.com (formerly Technology by Design)
WWW: http://www.pqtech.com 3300 Blue Ridge Court
Voice: (805) 497-9321 Thousand Oaks, CA 91362
FAX: (805) 497-9331

===================================================================================

########################################################################
# Test code begins here
########################################################################

set req 0
proc pollResponseCb {reqId status index values} {
puts "pollResponseCb: reqId=$reqId status=$status index=$index values=$values"
}

proc sendPoll {oidList} {
global ::req
global ::s
puts "sending request $req: $oidList"
$s get $oidList {pollResponseCb %R %E %I [list %V]}
incr req
}

set s [snmp session -address 206.250.77.4 -timeout 5]
for {set i 1} {$i <= 10} {incr i} {
sendPoll "ifIndex.1"
sendPoll "ifDescr.1"
sendPoll "ifMtu.1"
sendPoll "ifSpeed.1"
sendPoll "ifPhysAddress.1"
sendPoll "ifAdminStatus.1"
sendPoll "ifOperStatus.1"
sendPoll "ifLastChange.1"
sendPoll "ifInOctets.1"
sendPoll "ifInUcastPkts.1"
sendPoll "ifInUcastPkts.1"
sendPoll "ifInNUcastPkts.1"
sendPoll "ifInDiscards.1"
sendPoll "ifInErrors.1"
sendPoll "ifInUnknownProtos.1"
sendPoll "ifOutOctets.1"
sendPoll "ifOutUcastPkts.1"
sendPoll "ifOutNUcastPkts.1"
sendPoll "ifOutDiscards.1"
sendPoll "ifOutErrors.1"
sendPoll "ifOutQLen.1"
sendPoll "ifSpecific.1"
after 4000
}

----- Begin Included Message -----

>From owner-tkined@ibr.cs.tu-bs.de Tue Sep 10 05:54:31 1996
Date: Tue, 10 Sep 1996 05:47:16 +0200
From: Juergen Schoenwaelder <schoenw@cs.utwente.nl>
To: michele@pqtech.com
Cc: tkined@ibr.cs.tu-bs.de
Subject: Re: Peculiar behaviour with snmp get - scotty 2.0.2
Content-Length: 2145

michele@pqtech.com (Michele Chen) said:

Michele> I'm running scotty 2.0.2 with itcl 2.0 under SunOS
Michele> 4.1.3 and am seeing very peculiar behaviour when I
Michele> send out a lot of SNMP get requests to a single agent.

[ ... problem description removed ... ]

Michele> First, any ideas on why this is happening and what I
Michele> can do to eliminate it? Also, any insights on using
Michele> 'update' would also help. Any thoughts would be
Michele> greatly appreciated.

Looks like a serious problem in 2.0.2. Can you check if the same
problem exists with 2.1.3 or later? If you do not have access to
2.1.3, can you please send me a small example script that triggers
this problem?

In general, you should not worry about how many async requests you
generate. The C code should take care of it and process them when
appropriate. However, there have been (and there still are) some
problems with protecting pointers to internal data structures during
callback processing. A typical problem is a SNMP session which is
destroyed during callback processing and leads to a dangling
pointer. Using "update" makes these things even more complicated
because you add more potentially dangling pointers to the execution
stack.

Your problem might also have to do with the fact that 2.0.2 deletes
the internal request data structure after callback processing. This
protects the request data structure but has strange effects since
events processed during the callback (e.g. "update") can trigger a
noResponse callback (a timeout occurs during callback processing since
the internal request has not yet been removed).

I hope to get rid of all these problems in the next 2.1.* patches by
adding Tcl_Preserve() and Tcl_Release() calls to protect whatever
needs protection. However, this needs good tests because it is easy to
miss something which leads either to a dangling pointer or a memory
leak.
Juergen

--
Juergen Schoenwaelder schoenw@cs.utwente.nl http://www.cs.utwente.nl/~schoenw
Computer Science Department, University of Twente,   (Fax: +31-53-489-3247)
P.O. Box 217, NL-7500 AE Enschede, The Netherlands.  (Tel. +31-53-489-3678)




----- End Included Message -----