[SNMP4J] Timeout question (Follow up)

[Sjoerd van Doorn]

Hello all,
 
I think I figured out what my problem is. The Network Elements I am querying (multithreaded) use an identical (e.g. non unique) authoritiveEngineID. The internal administration of the USM stores both UsmUserEntry and UsmTimeEntry based on the authoritiveEngineID.
I am aware that this is not according to RFC 3414, but there is nothing I can do about it.
Since the Network elements are also managed by others than me and changing the authoritiveEngineID would require regenerating all the access information for the other users, this is not the way to go.
I'm thinking about adding the target address as extra parameter to both the user and time table in the USM to make the SNMP4J library capable of handling non unique authoritiveEngineID's.
Please let me know if I'm the only one having problems like this or (hopefully) anyone else has encountered the same kind of problems and has a fix for it already.
Also, if you think I'm missing anything in my analysis of the code to be modified, please let me know.
 
Thanks in advance and best regards,
 
Sjoerd

--- On Fri, 2/27/09, Sjoerd van Doorn <sjoerdvandoorn at yahoo.com> wrote:

From: Sjoerd van Doorn <sjoerdvandoorn at yahoo.com>
Subject: Timeout question
To: "SNMP4j" <snmp4j at agentpp.org>
Date: Friday, February 27, 2009, 12:07 PM







Hello, 
 
I am using the v1.3.9c version of the library on a openSolaris platform we are setting and getting SNMP variables on appr. 40 devices that use snmp tables for the entries. 
Every now and then, the GetNext call times out for a reason I can't seem to figure out.
We are running v3 with AUTH_NOPRIV in synchonous mode.
I have made a wireshark trace and found that after doing some successfull getnext's, one of the responses is being missed by the library alhough received by the OS. 
Normally this would have been covered by the retry, however, the retry sends the request with a different msgAuthoritiveEgineBoots and msgAuthoritiveEngineTime however the msgAuthoritiveEngineID remains the same. 
I think the response is causing the USM data to become invalid, I can't however seem to figure out why. 
One of the next things for me is try to run the library wih debug logging enabled. 
I hope by posting this message here, my problem description does ring a bell to someone and he can help me to address the correct piece of code in the library. 
I'm looking for the negotiation part for the msgAuthoritve items, I think it is in the retry mechanism of Snmp.java, but I cannot find where the enginetime, engineBoots are being reconfigured. 
Also 2 review comments:
1:
 Can someone explain to me why on line 656 of MPv3.java:
 {snip}
 // get length of scoped PDU 
 int scopedPDULength = pdu.getBERLength(); 
 BEROutputStream scopedPdu = 
 new BEROutputStream(ByteBuffer.allocate(scopedPDULength)); 
 {/snip} 
 takes the length of the PDU instead of the scoped PDU ? 
2:
    On line 709 of USM.java I think the wrong constant is being counted (e.g. statsNotInTime i.s.o. statsUnknownEngineId) 
Thanks in advance and hopefully someone can help me. 

Regards, Sjoerd