[SNMP4J] Behaviour of ResponseListener in SNMP V3
Frank Fock
fock at agentpp.com
Wed Oct 5 22:55:59 CEST 2016
Hi Peter,
From the provided send call alone, I cannot verify if the parameters
are correctly
setup. The SnmpUserTarget.this, for example, might not work if called in
a constructor
of that class.
The pdu instance might be used concurrently by another thread (with same
or different
request ID), which would corrupt the pending request management.
Best regards,
Frank
Am 05.10.2016 um 08:14 schrieb Peter Verthez:
> Hi Frank,
>
> The call of the send method was in the last line of my code snippet:
> session is an Snmp object.
>
> Best regards,
> Peter.
>
>
> On 4/10/2016 20:12, Frank Fock wrote:
>>
>> Hi Peter,
>>
>> How do call the send method? Is the listener set there?
>> All fields null should not happen normally....
>>
>> Best regards,
>> Frank
>>
>> Am 04.10.2016 um 11:18 schrieb Peter Verthez:
>>> Hi Frank,
>>>
>>> Our code is simply:
>>>
>>> ResponseListener respListener = new
>>> ResponseListener() {
>>> @Override
>>> public void onResponse(ResponseEvent event) {
>>> // canceling is required as per SNMP4J
>>> documentation
>>> ((Snmp)event.getSource()).cancel(event.getRequest(), this);
>>> PDU response = event.getResponse();
>>> updateStats(session, agentId, startTime,
>>> response);
>>> listener.onResponse(response,
>>> event.getUserObject());
>>> }
>>> };
>>>
>>> session.send(pdu, SnmpUserTarget.this,
>>> userContext, respListener);
>>>
>>> It doesn't reach even the first line of the onResponse method.
>>>
>>> I've been debugging a little, and the PendingRequest.run() method in
>>> the Snmp class is always being exited because all fields are null,
>>> and so it never calls the onResponse method on the listener. This
>>> is also what the debug message says:
>>>
>>> 2016-09-28 16:43:36,861 DEBUG [SNMP4J Timer]-[org.snmp4j.Snmp]
>>> PendingRequest canceled key=null, pdu=null, target=null,
>>> transport=null, listener=null
>>>
>>> I've then put a breakpoint in the cancel() method, and it gets run
>>> when the following report is coming in (copied from the debugger):
>>>
>>> REPORT[{contextEngineID=80:00:02:7d:03:00:90:d0:6d:fa:bc,
>>> contextName=nt}, requestID=0, errorStatus=0, errorIndex=0,
>>> VBS[1.3.6.1.6.3.15.1.1.3.0 = 18]]
>>>
>>> Best regards,
>>> Peter.
>>>
>>>
>>> On 3/10/2016 23:06, Frank Fock wrote:
>>>> Hi Peter,
>>>>
>>>> Yes, the ResponseEvent should be returned after the timeout with a
>>>> null response.
>>>> From the log, it is unclear why you do not get the event. Is there
>>>> an if-statement
>>>> that ignores the ResponseEvent with null response in your code?
>>>>
>>>> Best regards,
>>>> Frank
>>>>
>>>> Am 30.09.2016 um 10:12 schrieb Peter Verthez:
>>>>> Hi Frank,
>>>>>
>>>>> If we are using asynchronous SNMP calls with SNMPv3, what should
>>>>> be the behaviour in case of timeout, when you used wrong
>>>>> credentials such as a wrong user name. Should the
>>>>> ResponseListener always be triggered, with event.getResponse() =
>>>>> null, after the timeout?
>>>>>
>>>>> I would expect that, but it looks like this is not what I'm
>>>>> seeing: the ResponseListener does not seem to be triggered in that
>>>>> case. So this means that our application never knows that a
>>>>> timeout occurred. We are using currently SNMP4J 2.5.0. Debug
>>>>> logging from SNMP4J:
>>>>>
>>>>> 2016-09-28 16:43:31,768 DEBUG
>>>>> [JM-49-Ping-Ping-4]-[org.snmp4j.Snmp] Running pending async
>>>>> request with handle PduHandle[1071987217] and retry count left 1
>>>>> 2016-09-28 16:43:31,768 DEBUG
>>>>> [JM-49-Ping-Ping-4]-[org.snmp4j.transport.DefaultUdpTransportMapping]
>>>>> Sending message to 135.249.41.44/161 with length 268:
>>>>> 30:82:01:08:02:01:01:04:06:70:75:62:6c:69:63:a0:81:fa:02:04:3f:e5:3a:11:02:01:00:02:01:00:30:81:eb:30:10:06:0c:2b:06:01:04:01:84:7d:3d:01:09:03:00:05:00:30:11:06:0d:2b:06:01:04:01:84:7d:3d:01:17:01:06:00:05:00:30:10:06:0c:2b:06:01:04:01:84:7d:3d:01:0b:09:00:05:00:30:10:06:0c:2b:06:01:04:01:84:7d:3d:01:0b:02:00:05:00:30:12:06:0e:2b:06:01:04:01:84:7d:3d:01:23:3c:03:02:00:05:00:30:0c:06:08:2b:06:01:02:01:01:03:00:05:00:30:11:06:0d:2b:06:01:04:01:84:7d:3d:01:17:01:07:00:05:00:30:0c:06:08:2b:06:01:02:01:01:02:00:05:00:30:11:06:0d:2b:06:01:04:01:84:7d:3d:01:17:01:03:00:05:00:30:10:06:0c:2b:06:01:04:01:84:7d:3d:01:09:0d:00:05:00:30:12:06:0e:2b:06:01:04:01:84:7d:3d:01:17:02:01:04:01:05:00:30:11:06:0d:2b:06:01:04:01:84:7d:3d:01:09:1c:01:00:05:00:30:11:06:0d:2b:06:01:04:01:84:7d:3d:01:09:1c:02:00:05:00
>>>>> 2016-09-28 16:43:35,771 DEBUG [SNMP4J Timer]-[org.snmp4j.Snmp]
>>>>> Running pending async request with handle PduHandle[1071987217]
>>>>> and retry count left 0
>>>>> 2016-09-28 16:43:35,771 DEBUG [SNMP4J
>>>>> Timer]-[org.snmp4j.transport.DefaultUdpTransportMapping] Sending
>>>>> message to 135.249.41.44/161 with length 268:
>>>>> 30:82:01:08:02:01:01:04:06:70:75:62:6c:69:63:a0:81:fa:02:04:3f:e5:3a:11:02:01:00:02:01:00:30:81:eb:30:10:06:0c:2b:06:01:04:01:84:7d:3d:01:09:03:00:05:00:30:11:06:0d:2b:06:01:04:01:84:7d:3d:01:17:01:06:00:05:00:30:10:06:0c:2b:06:01:04:01:84:7d:3d:01:0b:09:00:05:00:30:10:06:0c:2b:06:01:04:01:84:7d:3d:01:0b:02:00:05:00:30:12:06:0e:2b:06:01:04:01:84:7d:3d:01:23:3c:03:02:00:05:00:30:0c:06:08:2b:06:01:02:01:01:03:00:05:00:30:11:06:0d:2b:06:01:04:01:84:7d:3d:01:17:01:07:00:05:00:30:0c:06:08:2b:06:01:02:01:01:02:00:05:00:30:11:06:0d:2b:06:01:04:01:84:7d:3d:01:17:01:03:00:05:00:30:10:06:0c:2b:06:01:04:01:84:7d:3d:01:09:0d:00:05:00:30:12:06:0e:2b:06:01:04:01:84:7d:3d:01:17:02:01:04:01:05:00:30:11:06:0d:2b:06:01:04:01:84:7d:3d:01:09:1c:01:00:05:00:30:11:06:0d:2b:06:01:04:01:84:7d:3d:01:09:1c:02:00:05:00
>>>>> 2016-09-28 16:43:36,861 DEBUG [SNMP4J Timer]-[org.snmp4j.Snmp]
>>>>> PendingRequest canceled key=null, pdu=null, target=null,
>>>>> transport=null, listener=null
>>>>> 2016-09-28 16:43:43,771 DEBUG [SNMP4J Timer]-[org.snmp4j.Snmp]
>>>>> Request timed out: 1071987217
>>>>> 2016-09-28 16:43:43,772 DEBUG [SNMP4J Timer]-[org.snmp4j.Snmp]
>>>>> Cancelling pending request with handle PduHandle[1071987217]
>>>>>
>>>>> Best regards,
>>>>> Peter.
>>>>>
>>>>
>>>
>>>
>>
>
>
--
---
AGENT++
Maximilian-Kolbe-Str. 10
73257 Koengen, Germany
https://agentpp.com
Phone: +49 7024 8688230
Fax: +49 7024 8688231
More information about the SNMP4J
mailing list