[SNMP4J] Timeout issue with snmp4j-2.3.4.jar

[Mark Ponthier]

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 <fock at agentpp.com>
Sent: Tuesday, April 16, 2019 2:49:41 PM
To: Mark Ponthier
Cc: snmp4j at agentpp.org
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 <mponthier at firescope.com> 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
> SNMP4J at agentpp.org
> https://oosnmp.net/mailman/listinfo/snmp4j