Re: [tkined] async SNMP requtest

Juergen Schoenwaelder (schoenw@ibr.cs.tu-bs.de)
Wed, 24 Jun 1998 12:19:13 +0200

>>>>> Simon Chow writes:

Simon> One of my co-worker is writing some script in Scotty, he found
Simon> that the following async snmp requtest does not get excuted
Simon> immediately in scotty 2.1.9, the command return immediately
Simon> with the request ID, however, "snoop" indicates that no packet
Simon> is being send out on the SUN interface.

Simon> It does not matter how longer we wait (we waited for over 5
Simon> minutes) or how many async request we send (we send over 300),
Simon> no packet was send and call back script were not executed.

It seems to work fine here on our Solaris 5.5.1 machines with
Tcl8.0. Which OS and which version of Tcl are you using?

Simon> I played with the problem a bit more, here is what I found: -
Simon> scotty 2.1.5: async request alway send out immediately - scotty
Simon> 2.1.7: first 10 async request send out immediately, after that,
Simon> request get queued up - scotty 2.1.9: async request almost
Simon> always get queued up

Do you have any special session configurations? The default is a
window of 10 messages that are permitted on the wire (which would
explain the observed behaviour of scotty version 2.17) and an
inter-message delay of 0 ms.

The code basically does the following. When sending an asynchronous
SNMP message, a Tcl timer is started to realize the timeout. Messages
are queued if the window is already filled up. Whenever we receive a
timeout or a response, the queue is checked and queued messages are
send out until the window is filled up.

So, even if you do not get responses or the responses are invalid,
there should be some progress and the queue should get empty.

Simon> It seems to me that this is a scotty bug introduced in version
Simon> 2.1.7, was there any change to the way the TCL event loop
Simon> handle async event in 2.1.7?

I checked the diffs but I could not find anything that might affect
the queue handling in the SNMP implementation. Anyway, here is some
more information how one can debug these things. Here is a little test
script that sends SNMP requests to a non existing device.

snmp watch on
set s [snmp session -address 1.2.3.4 -window 2 -delay 0 -retries 0]
for {set i 0} {$i < 4} {incr i} { $s getnext sysUpTime {} }; puts "****"
snmp wait

Below is the output generated by running this little script. I will
try to explain what it shows so that you can run similar tests in
order to track down the problem.

get-next-request 14758 noError
1. sysUpTime
send 40 bytes [1.2.3.4:161]:
3026 0201 0004 0670 7562 6c69 63a1 1902
0239 a602 0100 0201 0030 0d30 0b06 072b
0601 0201 0103 0500
get-next-request 13399 noError
1. sysUpTime
send 40 bytes [1.2.3.4:161]:
3026 0201 0004 0670 7562 6c69 63a1 1902
0234 5702 0100 0201 0030 0d30 0b06 072b
0601 0201 0103 0500
get-next-request 30018 noError
1. sysUpTime
get-next-request 1542 noError
1. sysUpTime
****
send 40 bytes [1.2.3.4:161]:
3026 0201 0004 0670 7562 6c69 63a1 1902
0275 4202 0100 0201 0030 0d30 0b06 072b
0601 0201 0103 0500
send 40 bytes [1.2.3.4:161]:
3026 0201 0004 0670 7562 6c69 63a1 1902
0206 0602 0100 0201 0030 0d30 0b06 072b
0601 0201 0103 0500

For every SNMP request made in the for loop, you can see the SNMP
request type, the request ID, the error status and the varbind list.
The first two requests are directly send out over the network. This is
indicated by the SNMP packet dump. The 3rd and 4th request are not
send out immediately and queued. The four stars are printed once the
loop terminates. You will see a delay after the stars have been
printed because the SNMP engine is waiting for a response until it
gets a timeout. This timeout causes the SNMP engine to check the queue
and this causes the queues messages to be send out on the network.
(Note, I did set retries to 0. Otherwise, there would be a couple of
retries in between.)

Please run this or similar scripts on your system in order to track
down what is going on. If you do not get any packet dumps, than there
is a fundamental problem with your scotty binary and we have to dive
deeper in order to find out if it is a Tcl bug or a Tnm bug.

Juergen

Juergen Schoenwaelder schoenw@ibr.cs.tu-bs.de http://www.cs.tu-bs.de/~schoenw
Technical University Braunschweig, Dept. Operating Systems & Computer Networks
Bueltenweg 74/75, 38106 Braunschweig, Germany. (Tel. +49 531 / 391 3283)

--
!! This message is brought to you via the `tkined & scotty' mailing list.
!! Please do not reply to this message to unsubscribe. To subscribe or
!! unsubscribe, send a mail message to <tkined-request@ibr.cs.tu-bs.de>.
!! See http://wwwsnmp.cs.utwente.nl/~schoenw/scotty/ for more information.