But that means that the state set by schedule is not propagated to the
m_inner, which is the AsyncPendingRequest. That is causing the problem
here. Strange that we did not see this before, because we have this
TimerFactory already since 2009, but in any case that is the cause of
the issue.

I'll fix that at our end. But should this vulnerability in
PendingRequest.run() be examined at your end, so that we don't need to
do this workaround?

In any case, thanks for all your help!
Best regards,
Peter.
On 13/10/2016 8:56, Peter Verthez wrote:

Hi Frank,

That WrappedReportHandler is the following (because we otherwise don't
have visibility about reports in our logs):

I don't see how this can affect the processing (event is not modified
in the logReport method).

We are using the MessageDispatcherImpl from SNMP4J.
I'll debug further later today to verify the expectations that you have.
Thanks,
Peter.
On 12/10/2016 23:43, Frank Fock wrote:

Hi Peter,
I just seem to have found the cause: The class
"SecureSnmpFactory$WrappedReportHandler" is not part of SNMP4J
and so I assume that this implementation is causing the issue.
Best regards,
Frank
Am 12.10.2016 um 16:29 schrieb Peter Verthez:

Hi Frank,

I found it suspicious that there was no real explanation, so I went
back to my test, and unfortunately that test had succeeded with
SNMP4J 2.5.2 because the agent was genuinely not reachable... When I
tested again with an agent that should be reachable, I found the
same problem, also with SNMP4J 2.5.2.

I debugged a little in the SNMP4J code. The cancel is really
happening after the report message, with the following stack trace:

Daemon Thread [DefaultUDPTransportMapping_172.31.109.98/0]
(Suspended (breakpoint at line 1925 in Snmp$PendingRequest))

- the 'usmStatsUnknownUserNames' report that we get here is handled
in ReportProcessor.processReport
- the resend variable stays false, because it is not one of the 3
special cases given there in lines 1364-1380
- as a consequence, the else is entered in line 1402, which cancels
the request
- the cancel request returns false here (apparently state of the
PendingRequest is VIRGIN at that time), so that 'intime' is false on
Snmp.java line 1414, which causes the listener not to be called

So the question is: why is the state of the PendingRequest equal to
VIRGIN? Is this unexpected?

Best regards,
Peter.
On 11/10/2016 0:14, Frank Fock wrote:

Hi Peter,

Thank you for trying version 2.5.2, although it seems to be
inexplicable why the behavior changed.

There are no changes in 2.5.2 and 2.5.1 in the class Snmp.
Best regards,
Frank
Am 10.10.2016 um 13:27 schrieb Peter Verthez:

1. No, the code that I showed in a previous mail is verbatim
copy/pasted from our source code, the snmp.send method call
comes directly after the creation of the ResponseListener.

2. No, we don't have an explicit cancel anywhere in our code,
except inside the ResponseListener, as I showed in the code in
the previous mail (which isn't reached).

3. No, we are using the original SNMP4J source code.
I'll try with SNMP4J 2.5.2 to see whether that makes a difference.
Best regards,
Peter.
On 9/10/2016 16:36, Frank Fock wrote:

Hi Peter,

Sorry, my statement in my previous message was wrong. Please
ignore it, because
setting the request-id field to 0 in a REPORT PDU is OK: If
the request was encrypted
the command responder would have no chance to decode the
request-id field.
That's is why the command generator has to be able to match
the request anyway
by the message-id field. SNMP4J is capable of that, so far, no
problem.

With SNMP4J 2.5.2 (current release) I still could not
reproduce the issue.

My unit test works as expected and calls the ResponseListener.

From the code analysis, I see only three possibilities how the
behavior you observed

could happen:

1. The ReponseListener parameter is null (please check for a
typo in the parameter name

or a null assignment before the send call)

2. The pending request was cancelled by closing the Snmp
session or cancelling the request

(Normally this would have been reported in the log, but...)
3. You did not use the original SNMP4J source code.
Best regards,
Frank
Am 09.10.2016 um 10:33 schrieb Frank Fock:

Hi Peter,

The command responder is not setting the request-id correctly
in the REPORT PDU.
This is causing the issue on the SNMP4J side. Nevertheless,
SNMP4J should behave more
robust and should call the response listener after the
request times out.

I will add a corresponding unit test for that and fix it.
Best regards,
Frank
Am 07.10.2016 um 12:55 schrieb Peter Verthez:

OK, my apologies: I was copying the wrong traces. Here are
the correct ones. I've also added a logging message
"Received response " + event in the first line of the
ResponseListener.onResponse(), and the traces below show
that it is not coming.

Ah, maybe I copied the wrong traces then and that is the
source of the confusion (we have a mix of SNMPv2 and v3
agents).

Let me check...
Thanks,
Peter.
On 6/10/2016 21:45, Frank Fock wrote:

Hi Peter,

The PDU that is send is a SNMPv2c GET request and not a v3
request.
So this cannot be an issue with the USM or other v3
processing.

To be able to reproduce the issue I might need more
details. If it is indeed
a v3 request, I would like to have the log for it. In
addition,
is the "unknown user" locally unknown the the USM of the
command

sender or remotely unknown to the command responder.

If locally unknown, a exception is thrown during the send
call.

Best regards,
Frank
Am 06.10.2016 um 09:45 schrieb Peter Verthez:

Hi Frank,

The PDU instance is not used in another thread, only in
this one. All normal functionality works properly (we
started to use async requests 1.5 years ago), except for
this timeout due to a wrong security name being used. I'm
not sure whether that is a new regression or something
that wasn't tested before by our test team.

I'm not sure which further information I have to give, I
can't provide the full source code as this is a
proprietary product. If you want me to debug something
specific I can do that.

Best regards,
Peter.
On 5/10/2016 22:55, Frank Fock wrote:

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:

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:

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: