[Pysnmp-dev] Timeout calculation bug

[Mark M E. <mar...@ma...>]

Howdy,

I've been running PySNMP on some fairly slow hardware and I  
discovered an apparent bug related to calculating the "timeoutAt"  
time for a PDU.  The behavior I noticed was that according to  
wireshark, requests where occasionally being retransmitted  
significantly sooner than the 1 second default timeout.

After much spelunking and a liberal use of print statements, I  
discovered that PDUs were timing out earlier than expected.   
Occasionally they were timing out in a few hundredths of a second.   
It turns out that _sendPdu() and sendNotification() were truncating  
the calculated timeoutAt entry in the expectResponse parameter of  
snmpEngine.msgAndPduDsp.sendPdu(...).  What's happening is that  
timeoutAt is calculated as:

	timeout/100 + time.time()

But timeout is a TimeInterval instance which has a __div__ method  
that returns a new TimeInterval instance.  The TimeInterval also has  
__add__ and __radd__ methods, so the result of the addition of  
time.time() is also a TimeInterval.  So the calculation is essentially:

	TimeInterval(timeout/100) + TimeInterval(time.time())

aka

	int(timeout/100) + int(time.time())

Which results in a lot of truncation.  If timeout was ever less than  
1, then timeoutAt would never be greater than time.time().  But even  
with the default of timeout=TimeInterval(100), the truncation of  
time.time() is essentially always less than expected.

Anyway, I changed the calculation to:

	float(timeout)/100.0 + time.time()

and now everything seems to be running as expected without unexpected  
retransmits.

In my local checkout of PySNMP this change was required in:

	pysnmp/v4/entity/rfc3413/cmdgen.py:164
	pysnmp/v4/entity/rfc3413/ntforg.py:229

I can create a patch if you like, but it seems a bit overkill.  :-)

Regards,
Mark






--
This signature intentionally left blank.