[snmp] SNMP v3 discovery bug in 5.1

[Josh Bers]

Tim and Birgit,

I don't think that the latest code will fix it since 5.1 includes version
1.17 of UsmDiscoveryBean.java.

However, I believe that I have found the problem. It is in
SnmpContextv3Basis.java#addPdu(Pdu, boolean).
Here is the problem (it is one of transmitter thread starvation):

This method first calls super.addPdu(pdu). The parent method reserves a
Transmitter, however, this is risky since discovery has yet to be performed.
When discovery is performed, a timeout PduException is thrown, however, it
is not caught by the stack to clean up the transmitter assignment with
removePdu(reqId).

So the fix could be:

1. Move discovery in front of calling super.addPdu that way an exception
will not result in a tied up transmitter in the context.

2. Catch the PduException thrown by discovery and call removePdu(reqId)...

My preference is toward 1, where the ordering of creating and sending out a
req id is consistent: discovery req id is < original PDU req id. The way the
code currently operates it sends out the discovery req with id > original
req id which is then sent later... Somewhat confusing.

What do you think?

Josh

> -----Original Message-----
> From: Tim Panton [mailto:thp at westhawk.co.uk] 
> Sent: Friday, September 14, 2007 5:04 AM
> To: List for discussion of the Westhawk SNMP stack; Josh Bers
> Cc: 'Birgit Arkesteijn'; 'Jonathan Tung'; 'Stephane Blais'
> Subject: Re: [snmp] SNMP v3 discovery bug in 5.1
> 
> 
> 
> On 13 Sep 2007, at 21:27, Josh Bers wrote:
> 
> > Birgit,
> >
> > Here is output (tail end) from our run of a program that 
> isolates the 
> > problem of SNMP v3 not working correctly when an agent that is
> > unreachable,
> > becomes reachable. We started with the network cable unplugged and  
> > tried to
> > fetch sysUpTime from 128.89.68.66 , every 5 seconds we kick off a  
> > thread to
> > fetch (authPriv enabled). Around request #35 we plug it back in
> >
> > (search for Thread 41 started at: 1189713664742)
> >
> > It seems that there is an issue with context being destroyed while
> > still
> > sending/receiving PDU's from the remote agent.... not clear. Why  
> > isn't the
> > DiscoveryBean using the context pool mechanism and creating 
> its own  
> > context
> > directly?
> >
> > ps. this was run using westhawk 5.1 from a windows XP box with java
> > 1.4.2
> > talking to a linux box:
> 
> Hi,
> I think this bug is fixed in the current CVS -
> see :
> 
> http://westhawksnmp.cvs.sourceforge.net/westhawksnmp/westhawks
nmp/src/ 
uk/co/westhawk/snmp/beans/UsmDiscoveryBean.java?r1=1.16&r2=1.17

Tim.