Frank,

Thanks for the response! The code I sent was more to show the calls I'm making. 
The actual code is only creating the USM once, but I am incorrectly creating an 
Snmp instance for each request which I will correct.


Since my code is doing SNMPv1, SNMPv2 and SNMPv3, do I need a different Snmp 
instance for each of these?

Can I have multiple threads operating on the same Snmp instance concurrently?


Thanks!


Mark Ponthier | Senior Vice President, Engineering

www.firescope.com<http://www.firescope.com/> | Office: 214.296.9243 x451 | 
Mobile: 214.578.3676

________________________________
From: Frank Fock <[email protected]>
Sent: Tuesday, April 16, 2019 2:49:41 PM
To: Mark Ponthier
Cc: [email protected]
Subject: Re: [SNMP4J] Timeout issue with snmp4j-2.3.4.jar

Hi Mark,

Increasing the timeout is only helpful, if the agent could be in a CPU overload 
situation or if there is a network congestion by large IP packets.
In your case, the agent seems to simply “forget” to process the request, maybe 
by an overload or other task, maybe because the UDP receive buffer is flooded.

To be sure, that the agent is the problem you could sniff on the network with 
Wireshark for example.

Your code seems to be creating a Snmp instance and USM for each requests, which 
is total overkill. Especially, the calling “listen()” is very “expensive” 
because it binds a network port. Doing this every second could easily block all 
ports on your system and might cause a high CPU load - because the SNMPv3 keys 
need to be calculated each time fresh.
Please reuse the Snmp and the associated USM for all subsequent requests.

Best regards,
Frank


> On 16. Apr 2019, at 18:55, Mark Ponthier <[email protected]> wrote:
>
> I have a program that does an SNMP GET every second against a network device 
> using SNMPv3. It is random, but after around a thousand or so requests, it 
> times out, and then it starts working again. Regardless of the specified 
> timeout or the number of retries, it waits the entire time period and then 
> returns a null response PDU. If I have a timeout of 1000ms and retries of 1, 
> it will timeout after 2sec. If I have a timeout of 20000ms and retries of 1, 
> it will timeout after 40sec. So the amount of the timeout is not the issue 
> here. When it decides to timeout it will do so regardless if I wait 2 seconds 
> or 40 seconds. The typical response time is usually 5-10ms. I'm wondering if 
> this is normal behavior, an issue in the library, or if I just have something 
> wrong in my code (see below). Less frequently this is also a problem with 
> SNMPv2. I really appreciate any help or ideas you may have!
>
>
> OctetString localEngineId = new OctetString(MPv3.createLocalEngineID());
> USM usm = new USM(SecurityProtocols.getInstance(), localEngineId, 0);
> SecurityModels.getInstance().addSecurityModel(usm);
>
> String oid = "1.3.6.1.2.1.1.1.0";
> PDU result = new ScopedPDU();
> result.setType(PDU.GET);
> result.add(new VariableBinding(new OID(oid)));
> Snmp snmp = new Snmp(new DefaultUdpTransportMapping());
> usm.addUser(securityNameOctet, new UsmUser(securityNameOctet, authProtocol, 
> new OctetString(authPassPhrase), privProtocol, new 
> OctetString(privPassPhrase)));
> snmp.listen();
>
> String addrStr = "10.0.22.33/161";
> Address targetAddress = GenericAddress.parse(addrStr);
>
> UserTarget userTarget = new UserTarget();
> userTarget.setAddress(targetAddress);
> userTarget.setRetries(numRetries);
> userTarget.setTimeout(timeout);
> userTarget.setVersion(SnmpConstants.version3);
> userTarget.setSecurityName(new OctetString(securityName));
> userTarget.setSecurityLevel(SecurityLevel.AUTH_PRIV);
>
> ResponseEvent responseEvent = snmp.send(pdu, target);
> PDU responsePDU = responseEvent.getResponse();
>
> if (responsePDU == null) {
> LOGGER.error(;
> LOGGER.error("SNMP GET timed out: addrStr[" + addrStr + "], oid[" + oid + 
> "]");
> }
>
>
>
> Mark Ponthier | Senior Vice President, Engineering
>
> www.firescope.com<http://www.firescope.com/> | Office: 214.296.9243 x451 | 
> Mobile: 214.578.3676
> _______________________________________________
> SNMP4J mailing list
> [email protected]
> https://oosnmp.net/mailman/listinfo/snmp4j

_______________________________________________
SNMP4J mailing list
[email protected]
https://oosnmp.net/mailman/listinfo/snmp4j

Reply via email to