Here's what I got using scotty:
% snmp watch on
% snmp0 get sysUpTime.0 {puts "gotcha"}
get-request 1966251996 noError
1. sysUpTime.0
send 43 bytes [202.148.0.5:161]:
3029 0201 0004 0670 7562 6c69 63a0 1c02
0475 329f dc02 0100 0201 0030 0e30 0c06
082b 0601 0201 0103 0005 00
1966251996
% recv 47 bytes [202.148.0.5:161]:
302d 0201 0004 0670 7562 6c69 63a2 2002
0475 329f dc02 0100 0201 0030 1230 1006
082b 0601 0201 0103 0043 0400 81b6 a4
response 1966251996 noError
1. 1.3.6.1.2.1.1.3.0 TimeTicks {0d 23:36:49.00}
gotcha
While using tclsh8.0 (came from itclsh 3.0a):
% snmp0 get sysUpTime {puts "gotcha"}
1624334619
%
% snmp wait
gotcha
% snmp watch on
% snmp0 get sysUpTime {puts "gotcha"}
get-request 477176998 noError
1. sysUpTime
send 42 bytes [202.148.0.5:161]:
3028 0201 0004 0670 7562 6c69 63a0 1b02
041c 7124 a602 0100 0201 0030 0d30 0b06
072b 0601 0201 0103 0500
477176998
%
% snmp wait
gsend 42 bytes [202.148.0.5:161]:
3028 0201 0004 0670 7562 6c69 63a0 1b02
041c 7124 a602 0100 0201 0030 0d30 0b06
072b 0601 0201 0103 0500
recv 47 bytes [202.148.0.5:161]:
302d 0201 0004 0670 7562 6c69 63a2 2002
041c 7124 a602 0100 0201 0030 1230 1006
082b 0601 0201 0103 0043 0400 81f0 10
response 477176998 noError
1. 1.3.6.1.2.1.1.3.0 TimeTicks {0d 23:39:16.00}
gotcha
%
TIA
Juergen Schoenwaelder wrote:
> >>>>> 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.
-- Rachmat Kosasih P.T. Dyviacom Intrabumi ph: +62 (021) 5257520 fx: +62 (021) 5257634
-- !! 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.