[SNMP4J] Behaviour of ResponseListener in SNMP V3

[Frank Fock]

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