[SNMP4J] Behaviour of ResponseListener in SNMP V3

[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.
>>
>


-- 
Peter Verthez
Systems Engineer Network Mgt.
Tel: (+32) 3 240 84 50 | Alcanet:
Fax: (+32) 3 240 84 59 | (6)2605

Nokia Corporation
Copernicuslaan 50, 2018 Antwerp, Belgium
Fortis 220-0002334-42
VAT BE 0404 621 642 Register of Legal Entities Antwerp

***
This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law.  If you are not the intended recipient, you should delete this message.  Any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited without the prior consent of its author.