Re: [SNMP4J] Behaviour of ResponseListener in SNMP V3

2016-10-13 Thread Peter Verthez 

Hi Frank,

OK, I found the issue.   We are providing our own TimerFactory, because 
we found that in certain cases the timer of SNMP4J could leak 
exceptions, which was causing problems in our application (a timer is 
not run anymore when one of its tasks is throwing an exception, see e.g. 
http://bryanpendleton.blogspot.fr/2009/05/timertask-exception-handling.html 
for details).


So basically we have a TimerTask that encapsulates the TimerTask from 
SNMP4J and which does:


@Override
public void run() {
try {
m_inner.run();
}
catch (Exception t) {
m_log.error("Exception leaked out of TimerTask", t);
}
}

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):


private static class WrappedReportHandler implements ReportHandler {

private final ReportHandler m_inner;
private final SnmpTracer m_snmpTracer = new Log4jSnmpTracer();

public WrappedReportHandler(ReportHandler inner) {
m_inner = inner;
}

@Override
public void processReport(PduHandle pduHandle, 
CommandResponderEvent event) {

m_snmpTracer.logReport(event);
m_inner.processReport(pduHandle, event);
}
}

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))

owns: Snmp$AsyncPendingRequest  (id=36087)
Snmp$AsyncPendingRequest(Snmp$PendingRequest).cancel() line: 1925
Snmp$ReportProcessor.processReport(PduHandle, 
CommandResponderEvent) line: 1409
SecureSnmpFactory$WrappedReportHandler.processReport(PduHandle, 
CommandResponderEvent) line: 157

Snmp.processPdu(CommandResponderEvent) line: 1248
MessageDispatcherImpl.fireProcessPdu(CommandResponderEvent) line: 691
MessageDispatcherImpl.dispatchMessage(TransportMapping, 
MessageProcessingModel, Address, BERInputStream, 
TransportStateReference) line: 310
MessageDispatcherImpl.processMessage(TransportMapping, Address, 
BERInputStream, TransportStateReference) line: 387
MessageDispatcherImpl.processMessage(TransportMapping, Address, 
ByteBuffer, TransportStateReference) line: 347
DefaultUdpTransportMapping(AbstractTransportMapping).fireProcessMessage(Address, 
ByteBuffer, TransportStateReference) line: 76

DefaultUdpTransportMapping$ListenThread.run() line: 425
Thread.run() line: 745

Here is what I find (with SNMP4J 2.5.2):
- 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.

Bes

Re: [SNMP4J] Behaviour of ResponseListener in SNMP V3

2016-10-13 Thread Peter Verthez 

Hi Frank,

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


private static class WrappedReportHandler implements ReportHandler {

private final ReportHandler m_inner;
private final SnmpTracer m_snmpTracer = new Log4jSnmpTracer();

public WrappedReportHandler(ReportHandler inner) {
m_inner = inner;
}

@Override
public void processReport(PduHandle pduHandle, 
CommandResponderEvent event) {

m_snmpTracer.logReport(event);
m_inner.processReport(pduHandle, event);
}
}

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))

owns: Snmp$AsyncPendingRequest  (id=36087)
Snmp$AsyncPendingRequest(Snmp$PendingRequest).cancel() line: 1925
Snmp$ReportProcessor.processReport(PduHandle, 
CommandResponderEvent) line: 1409
SecureSnmpFactory$WrappedReportHandler.processReport(PduHandle, 
CommandResponderEvent) line: 157

Snmp.processPdu(CommandResponderEvent) line: 1248
MessageDispatcherImpl.fireProcessPdu(CommandResponderEvent) line: 
691
MessageDispatcherImpl.dispatchMessage(TransportMapping, 
MessageProcessingModel, Address, BERInputStream, 
TransportStateReference) line: 310
MessageDispatcherImpl.processMessage(TransportMapping, Address, 
BERInputStream, TransportStateReference) line: 387
MessageDispatcherImpl.processMessage(TransportMapping, Address, 
ByteBuffer, TransportStateReference) line: 347
DefaultUdpTransportMapping(AbstractTransportMapping).fireProcessMessage(Address, 
ByteBuffer, TransportStateReference) line: 76

DefaultUdpTransportMapping$ListenThread.run() line: 425
Thread.run() line: 745

Here is what I find (with SNMP4J 2.5.2):
- 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:

Traces now, for info:

2016-10-10 13:25:54,180 DEBUG 
[JM-45-Ping-Ping-7]-[org.snmp4j.security.UsmUserTable] Adding user 
verthezp_wrong2 = 
UsmUser[secName=verthezp_wrong2,authProtocol=1.3.6.1.6.3.10.1.1.3,authPassphrase=12345678,privProtocol=null,privPassphrase=null,localizationEngineID=null]
2016-10-10 13:25:54,182 DEBUG 
[JM-45-Ping-Ping-7]-[org.snmp4j.security.USM] RFC3414 §3.1.4.b 
Outgoing message is not encrypted
2016-10-10 13:25:54,182 DEBUG 
[JM-45-Ping-Ping-7]-[org.snmp4j.mp.MPv3] Adding cache entry: 
StateReference[msgID=16001,pduHandle=PduHandle[922855848],securityEngineID=,securityModel=org.snmp4j.security.USM@137719b6,securityName=verthezp_wrong2,securityLevel=1,contextEngineID=,contextName=nt,retryMsgIDs=null] 

2016-10-10 13:25:54,182 DEBUG [JM-45-Ping-Ping-7]-[org.snmp4j.Snmp] 
Running pending async request with handle PduHandle[922855848] and 
retry count left 1
2016-10-10 13:25:54,182 DEBUG 
[JM-45-Ping-Ping-7]-[org.snmp4j.transport.DefaultUdpTransportMapping] 
Sending message to 135.249.41.7/161 with length 61: 
30:3b:02:01:03:30:0f:02:02:3e:81:02:03:00:ff:ff:04:01:04:02:01:03:04:10:30:0e:04:00:02:01:00:02:01:00:04:00:04:00:04:00:30:13:04:00:04:02:6e:74:a0:0b:02:01:00:02:01:00:02:01:00:30:00
2016-10-10 13:25:58,187 DEBUG [SNM

Re: [SNMP4J] Behaviour of ResponseListener in SNMP V3

2016-10-10 Thread Peter Verthez 

Traces now, for info:

2016-10-10 13:25:54,180 DEBUG 
[JM-45-Ping-Ping-7]-[org.snmp4j.security.UsmUserTable] Adding user 
verthezp_wrong2 = 
UsmUser[secName=verthezp_wrong2,authProtocol=1.3.6.1.6.3.10.1.1.3,authPassphrase=12345678,privProtocol=null,privPassphrase=null,localizationEngineID=null]
2016-10-10 13:25:54,182 DEBUG 
[JM-45-Ping-Ping-7]-[org.snmp4j.security.USM] RFC3414 §3.1.4.b Outgoing 
message is not encrypted
2016-10-10 13:25:54,182 DEBUG [JM-45-Ping-Ping-7]-[org.snmp4j.mp.MPv3] 
Adding cache entry: 
StateReference[msgID=16001,pduHandle=PduHandle[922855848],securityEngineID=,securityModel=org.snmp4j.security.USM@137719b6,securityName=verthezp_wrong2,securityLevel=1,contextEngineID=,contextName=nt,retryMsgIDs=null]
2016-10-10 13:25:54,182 DEBUG [JM-45-Ping-Ping-7]-[org.snmp4j.Snmp] 
Running pending async request with handle PduHandle[922855848] and retry 
count left 1
2016-10-10 13:25:54,182 DEBUG 
[JM-45-Ping-Ping-7]-[org.snmp4j.transport.DefaultUdpTransportMapping] 
Sending message to 135.249.41.7/161 with length 61: 
30:3b:02:01:03:30:0f:02:02:3e:81:02:03:00:ff:ff:04:01:04:02:01:03:04:10:30:0e:04:00:02:01:00:02:01:00:04:00:04:00:04:00:30:13:04:00:04:02:6e:74:a0:0b:02:01:00:02:01:00:02:01:00:30:00
2016-10-10 13:25:58,187 DEBUG [SNMP4J Timer]-[org.snmp4j.security.USM] 
RFC3414 §3.1.4.b Outgoing message is not encrypted
2016-10-10 13:25:58,187 DEBUG [SNMP4J Timer]-[org.snmp4j.mp.MPv3] Adding 
cache entry: 
StateReference[msgID=16002,pduHandle=PduHandle[922855848],securityEngineID=,securityModel=org.snmp4j.security.USM@137719b6,securityName=verthezp_wrong2,securityLevel=1,contextEngineID=,contextName=nt,retryMsgIDs=null]
2016-10-10 13:25:58,188 DEBUG [SNMP4J Timer]-[org.snmp4j.mp.MPv3] Adding 
previous message IDs [16001] to new entry 
StateReference[msgID=16002,pduHandle=PduHandle[922855848],securityEngineID=,securityModel=org.snmp4j.security.USM@137719b6,securityName=verthezp_wrong2,securityLevel=1,contextEngineID=,contextName=nt,retryMsgIDs=null]
2016-10-10 13:25:58,188 DEBUG [SNMP4J Timer]-[org.snmp4j.Snmp] Running 
pending async request with handle PduHandle[922855848] and retry count 
left 0
2016-10-10 13:25:58,188 DEBUG [SNMP4J 
Timer]-[org.snmp4j.transport.DefaultUdpTransportMapping] Sending message 
to 135.249.41.7/161 with length 61: 
30:3b:02:01:03:30:0f:02:02:3e:82:02:03:00:ff:ff:04:01:04:02:01:03:04:10:30:0e:04:00:02:01:00:02:01:00:04:00:04:00:04:00:30:13:04:00:04:02:6e:74:a0:0b:02:01:00:02:01:00:02:01:00:30:00
2016-10-10 13:26:06,188 DEBUG [SNMP4J Timer]-[org.snmp4j.Snmp] Request 
timed out: 922855848
2016-10-10 13:26:06,188 INFO  [SNMP4J 
Timer]-[com.alcatel.util.net.snmp.SnmpUserTarget] Received response 
org.snmp4j.event.ResponseEvent[source=org.snmp4j.Snmp@dbb54af]
2016-10-10 13:26:06,189 DEBUG [SNMP4J Timer]-[org.snmp4j.Snmp] 
Cancelling pending request with handle PduHandle[922855848]



Best regards,
Peter.


On 10/10/2016 13:25, Peter Verthez wrote:

Hi Frank,

I've tried now with SNMP4J 2.5.2 (downloaded by manually changing the 
download URL), and with that version I also can't reproduce the 
problem anymore: the ResponseListener is now called.


So we'll upgrade to that version.

Thanks,
Peter.



On 10/10/2016 8:19, Peter Verthez wrote:

Hi Frank,

Apparently the download page is not updated yet for SNMP4J 2.5.2?

http://www.snmp4j.org/html/download.html

Best regards,
Peter.


On 10/10/2016 7:58, Peter Verthez wrote:

Hi Frank,

Answers on your possibilities:

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

Re: [SNMP4J] Behaviour of ResponseListener in SNMP V3

2016-10-07 Thread Peter Verthez 
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:

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:8

Re: [SNMP4J] Behaviour of ResponseListener in SNMP V3

2016-10-06 Thread 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:

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

Re: [SNMP4J] Behaviour of ResponseListener in SNMP V3

2016-10-04 Thread 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

[SNMP4J] Behaviour of ResponseListener in SNMP V3

2016-09-30 Thread 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

___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j

Re: [SNMP4J] SNMPv3 problem with unhandled responses

2014-10-30 Thread Peter Verthez 

Hi Frank,

Our tester confirms that this patch indeed fixes the problem.

We'll use temporarily this locally built version in our product until 
there is a new official version available, so we are unblocked.


Thanks a lot for your quick help!

Best regards,
Peter.


On 29/10/2014 8:22, Peter Verthez wrote:

OK thanks, we'll try it out today.

Best regards,
Peter.


On 29/10/2014 1:39, Frank Fock wrote:

Hi Peter,

I have not finished to implement all new necessary unit tests yet, but
nevertheless I am quite sure, that chaning the following method in
MPv3 will fix the issue:

/**
 * Adds a codeStateReference/code to the cache.
 * The codePduHandle/code of the supplied entry will be set to
 * codenull/code while the entry is part of the cache, 
because the

 * cache uses a codeWeakHashMap/code internally which uses the
 * codePduHandle/code as key. When
 * @param entry
 *the state reference to add.
 * @return
 *{@link SnmpConstants#SNMP_MP_DOUBLED_MESSAGE} if the entry 
already

 *exists and {@link SnmpConstants#SNMP_MP_OK} on success.
 */
public synchronized int addEntry(StateReference entry) {
  if (logger.isDebugEnabled()) {
logger.debug(Adding cache entry: +entry);
  }
  StateReference existing =
  entries.get(entry.getPduHandle());
  if (existing != null) {
// reassign handle for comparison:
existing.setPduHandle(entry.getPduHandle());
if (existing.equals(entry)) {
  if (logger.isDebugEnabled()) {
logger.debug(Doubled message: +entry);
  }
  // clear it again to remove strong self-reference
  existing.setPduHandle(null);
  return SnmpConstants.SNMP_MP_DOUBLED_MESSAGE;
}
else if (existing.equalsExceptMsgID(entry)) {
  if (logger.isDebugEnabled()) {
logger.debug(Adding previous message IDs 
+existing.getMessageIDs()+  to new entry +entry);

  }
  entry.addMessageIDs(existing.getMessageIDs());
}
else if (logger.isDebugEnabled()) {
  logger.debug(New entry does not match existing, although 
request ID is the same +entry+ != +existing);

}
// clear it again to remove strong self-reference
existing.setPduHandle(null);
  }
  // add it
  PduHandle key = entry.getPduHandle();
  // because we are using a weak hash map for the cache, we need 
to null out

  // our key from the entry.
  entry.setPduHandle(null);
  entries.put(key, entry);
  return SnmpConstants.SNMP_MP_OK;
}


Best regards,
Frank


Am 27.10.2014 13:12, schrieb Peter Verthez:

Hi Frank,

Our tester has retried with the modified jar file, but there was no 
difference.


The log line Release PDU handle did not occur in the debug traces.

Best regards,
Peter.


On 27/10/2014 9:12, Peter Verthez wrote:

Hi Frank,

All tests are done on Solaris with an x86 processor.The JDKs 
are from Oracle:


  * for the SNMP4J 2.3.0 and 2.3.1 tests, JDK 7u45 is used
  * for the SNMP4J 2.0.1 problem at our customer, it's JDK 7u06

We'll test with the patch that you provided.

Thanks,
Peter.


On 27/10/2014 8:35, Frank Fock wrote:

Hi Peter,

Operarting system and JDK version (including whether it is a 
Oracle or 3rd party JRE) would be helpful

too.

I will analyze it. Meanwhile, you could try the following fix in 
Snmp.java:


  protected boolean resendRequest(PendingRequest request, PDU 
response) {

if (request.useNextPDU()) {
  request.responseReceived = false;
  synchronized (pendingRequests) {
pendingRequests.remove(request.key);
PduHandle holdKeyUntilResendDone = request.key;
request.key = null;
handleInternalResponse(response, request.pdu, 
request.target.getAddress());

try {
  sendMessage(request.pdu, request.target, 
request.transport, request);

}
catch (IOException e) {
  logger.error(IOException while resending request after 
RFC 5343 context engine ID discovery:  +

  e.getMessage(), e);
}
// now the previous retry can be released
if (logger.isDebugEnabled()) {
  logger.debug(Releasing PDU handle 
+holdKeyUntilResendDone);

}
holdKeyUntilResendDone = null;
  }
  return true;
}
return false;
  }


From my analysis, I thought this improvement would not have any 
effect on your issue,
but I am not 100% sure. I will have to exeactly analyze the 
request/response sequences

to be sure.

Best regards,
Frank


Am 27.10.2014 08:01, schrieb Peter Verthez:

Hi Frank,

We have now tried with both SNMP4J 2.3.0 and 2.3.1 and we're 
facing the same problem.


Can you investigate this?   Is there any more information we 
could provide?


Best regards,
Peter.


On 24/10/2014 8:17, Peter Verthez wrote:
OK, thanks, we'll try that (we are on the latest version in our 
latest release, but the customer

Re: [SNMP4J] SNMPv3 problem with unhandled responses

2014-10-27 Thread Peter Verthez 

Hi Frank,

We have now tried with both SNMP4J 2.3.0 and 2.3.1 and we're facing the 
same problem.


Can you investigate this?   Is there any more information we could provide?

Best regards,
Peter.


On 24/10/2014 8:17, Peter Verthez wrote:
OK, thanks, we'll try that (we are on the latest version in our latest 
release, but the customer is using an older release of our product).


Best regards,
Peter.


On 24/10/2014 2:16, Frank Fock wrote:

Hi Peter,

Please update to the latest version. There have been several fixes 
about race conditions
in the Snmp class regarding retries and the PduHandleCallback. The 
current implementation
seems to be OK regarding handling of the Message IDs and the MPv3 
Cache WeakHashMap.


Best regards,
Frank

Am 23.10.2014 12:34, schrieb Peter Verthez:

Hi Frank,

One of our customers has reported a problem with SNMPv3.  The 
version of our application that they use is using SNMP4J 2.0.1. For 
the particular SNMP request that has the problem, the agent is known 
to respond very slowly, so the timeout model for that particular 
request has been set to:

- a first timeout after 30 seconds, then a retransmission
- a second timeout after 60 seconds (so 90 seconds after the 
original request), then a retransmission
- a third timeout after 120 seconds (210 seconds after the original 
request)


Now, we observe the following behavior (you can also see that in the 
logs that I'm pasting below):


2014-10-22 10:42:33,428 = Original request
2014-10-22 10:43:03,430 = 1st retransmission
2014-10-22 10:43:37,444 = Response to original request (rejected)
2014-10-22 10:44:03,440 = 2nd retransmission
2014-10-22 10:44:41,466 = Response to 1st retransmission (rejected)
2014-10-22 10:45:45,539 = Response to 2nd retransmission (accepted)

So the problem that we see is that the first response (the response 
to the original request) is not accepted for some reason.   This 
looks similar to the problem SFJ-43, but that was fixed in SNMP4J 
2.0.0 according to the change log.   We are in the process of trying 
to reproduce it on SNMP4J 2.3.0, but I see no relevant change in the 
change log, so I guess there will be no difference.


The logs are the following (with some sensitive information removed):


2014-10-22 10:42:33,426 DEBUG 
[http-0.0.0.0-8080-30]-[org.snmp4j.security.UsmUserTable] Adding 
user removed = UsmUser 
[secName=removed,authProtocol=1.3.6.1.6.3.10.1.1.3,authPassphrase=removed,privProtocol=1.3.6.1.6.3.10.1.2.2,privPassphrase=removed,localizationEngineID=null]
2014-10-22 10:42:33,427 DEBUG 
[http-0.0.0.0-8080-30]-[org.snmp4j.mp.MPv3] Context engine ID of 
scoped PDU is empty! Setting it to authoritative engine ID: 
80:00:02:7d:03:00:0e:86:1e:5f:9b
2014-10-22 10:42:33,427 DEBUG 
[http-0.0.0.0-8080-30]-[org.snmp4j.security.USM] getUser 
(engineID=80:00:02:7d:03:00:0e:86:1e:5f:9b, securityName=removed)
2014-10-22 10:42:33,427 DEBUG 
[http-0.0.0.0-8080-30]-[org.snmp4j.security.USM] RFC3414 §3.1.4.a 
Outgoing message needs to be encrypted
2014-10-22 10:42:33,427 DEBUG 
[http-0.0.0.0-8080-30]-[org.snmp4j.security.PrivDES] Preparing 
decrypt_params.
2014-10-22 10:42:33,427 DEBUG 
[http-0.0.0.0-8080-30]-[org.snmp4j.security.PrivDES] Preparing iv 
for encryption.
2014-10-22 10:42:33,427 DEBUG 
[http-0.0.0.0-8080-30]-[org.snmp4j.security.PrivDES] Using padding.
2014-10-22 10:42:33,427 DEBUG 
[http-0.0.0.0-8080-30]-[org.snmp4j.security.PrivDES] Encryption 
finished.
2014-10-22 10:42:33,427 DEBUG 
[http-0.0.0.0-8080-30]-[org.snmp4j.mp.MPv3] Adding cache entry: 
StateReference[msgID=1547681362,pduHandle=PduHandle[1912160112],securityEngineID=80:00:02:7d:03:00:0e:86:1e:5f:9b,securityModel=org.snmp4j.security.USM@897ec81,securityName=removed,securityLevel=3,contextEngineID=80:00:02:7d:03:00:0e:86:1e:5f:9b,contextName=nt,retryMsgIDs=null] 

2014-10-22 10:42:33,428 DEBUG 
[http-0.0.0.0-8080-30]-[org.snmp4j.Snmp] Running pending sync 
request with handle PduHandle[1912160112] and retry count left 2
2014-10-22 10:42:33,428 DEBUG 
[http-0.0.0.0-8080-30]-[org.snmp4j.transport.DefaultUdpTransportMapping] 
Sending message to 124.150.10.52/161 with length 143: 
30:81:8c:02:01:03:30:11:02:04:5c:3f:be:52:02:03:00:ff:ff:04:01:07:02:01:03:04:3a:30:38:04:0b:80:00:02:7d:03:
00:0e:86:1e:5f:9b:02:01:05:02:03:00:f6:1c:04:09:31:40:72:61:6c:65:69:67:68:04:0c:aa:82:4f:0d:79:70:ab:03:54:1d:8d:07:04:08: 

00:00:00:05:1a:64:0a:89:04:38:56:b3:24:74:26:e8:bc:d0:be:5c:f4:6e:59:d6:ac:2e:35:2d:01:fd:91:3f:be:0e:75:31:aa:96:4d:9b:36:ab:27:e7:65:e6:e3:18:55: 


a6:1a:fc:be:cc:22:3c:92:47:6a:06:3b:e7:30:1a:16:2c


2014-10-22 10:43:03,430 DEBUG [Timer-30]-[org.snmp4j.mp.MPv3] Adding 
cache entry: 
StateReference[msgID=1547681458,pduHandle=PduHandle[1912160112],securityEngineID=80:00:02:7d:03:00:0e:86:1e:5f:9b,securityModel=org.snmp4j.security.USM@897ec81,securityName=removed,securityLevel=3,contextEngineID=80:00:02:7d:03:00:0e:86:1e:5f:9b,contextName=nt,retryMsgIDs=null]
2014-10-22 10

Re: [SNMP4J] SNMPv3 problem with unhandled responses

2014-10-27 Thread Peter Verthez 

Hi Frank,

All tests are done on Solaris with an x86 processor.The JDKs are 
from Oracle:


 * for the SNMP4J 2.3.0 and 2.3.1 tests, JDK 7u45 is used
 * for the SNMP4J 2.0.1 problem at our customer, it's JDK 7u06

We'll test with the patch that you provided.

Thanks,
Peter.


On 27/10/2014 8:35, Frank Fock wrote:

Hi Peter,

Operarting system and JDK version (including whether it is a Oracle or 
3rd party JRE) would be helpful

too.

I will analyze it. Meanwhile, you could try the following fix in 
Snmp.java:


  protected boolean resendRequest(PendingRequest request, PDU response) {
if (request.useNextPDU()) {
  request.responseReceived = false;
  synchronized (pendingRequests) {
pendingRequests.remove(request.key);
PduHandle holdKeyUntilResendDone = request.key;
request.key = null;
handleInternalResponse(response, request.pdu, 
request.target.getAddress());

try {
  sendMessage(request.pdu, request.target, request.transport, 
request);

}
catch (IOException e) {
  logger.error(IOException while resending request after RFC 
5343 context engine ID discovery:  +

  e.getMessage(), e);
}
// now the previous retry can be released
if (logger.isDebugEnabled()) {
  logger.debug(Releasing PDU handle +holdKeyUntilResendDone);
}
holdKeyUntilResendDone = null;
  }
  return true;
}
return false;
  }


From my analysis, I thought this improvement would not have any effect 
on your issue,
but I am not 100% sure. I will have to exeactly analyze the 
request/response sequences

to be sure.

Best regards,
Frank


Am 27.10.2014 08:01, schrieb Peter Verthez:

Hi Frank,

We have now tried with both SNMP4J 2.3.0 and 2.3.1 and we're facing 
the same problem.


Can you investigate this?   Is there any more information we could 
provide?


Best regards,
Peter.


On 24/10/2014 8:17, Peter Verthez wrote:
OK, thanks, we'll try that (we are on the latest version in our 
latest release, but the customer is using an older release of our 
product).


Best regards,
Peter.


On 24/10/2014 2:16, Frank Fock wrote:

Hi Peter,

Please update to the latest version. There have been several fixes 
about race conditions
in the Snmp class regarding retries and the PduHandleCallback. The 
current implementation
seems to be OK regarding handling of the Message IDs and the MPv3 
Cache WeakHashMap.


Best regards,
Frank

Am 23.10.2014 12:34, schrieb Peter Verthez:

Hi Frank,

One of our customers has reported a problem with SNMPv3. The 
version of our application that they use is using SNMP4J 2.0.1. 
For the particular SNMP request that has the problem, the agent is 
known to respond very slowly, so the timeout model for that 
particular request has been set to:

- a first timeout after 30 seconds, then a retransmission
- a second timeout after 60 seconds (so 90 seconds after the 
original request), then a retransmission
- a third timeout after 120 seconds (210 seconds after the 
original request)


Now, we observe the following behavior (you can also see that in 
the logs that I'm pasting below):


2014-10-22 10:42:33,428 = Original request
2014-10-22 10:43:03,430 = 1st retransmission
2014-10-22 10:43:37,444 = Response to original request (rejected)
2014-10-22 10:44:03,440 = 2nd retransmission
2014-10-22 10:44:41,466 = Response to 1st retransmission (rejected)
2014-10-22 10:45:45,539 = Response to 2nd retransmission (accepted)

So the problem that we see is that the first response (the 
response to the original request) is not accepted for some 
reason.   This looks similar to the problem SFJ-43, but that was 
fixed in SNMP4J 2.0.0 according to the change log.   We are in the 
process of trying to reproduce it on SNMP4J 2.3.0, but I see no 
relevant change in the change log, so I guess there will be no 
difference.


The logs are the following (with some sensitive information removed):


2014-10-22 10:42:33,426 DEBUG 
[http-0.0.0.0-8080-30]-[org.snmp4j.security.UsmUserTable] Adding 
user removed = UsmUser 
[secName=removed,authProtocol=1.3.6.1.6.3.10.1.1.3,authPassphrase=removed,privProtocol=1.3.6.1.6.3.10.1.2.2,privPassphrase=removed,localizationEngineID=null]
2014-10-22 10:42:33,427 DEBUG 
[http-0.0.0.0-8080-30]-[org.snmp4j.mp.MPv3] Context engine ID of 
scoped PDU is empty! Setting it to authoritative engine ID: 
80:00:02:7d:03:00:0e:86:1e:5f:9b
2014-10-22 10:42:33,427 DEBUG 
[http-0.0.0.0-8080-30]-[org.snmp4j.security.USM] getUser 
(engineID=80:00:02:7d:03:00:0e:86:1e:5f:9b, securityName=removed)
2014-10-22 10:42:33,427 DEBUG 
[http-0.0.0.0-8080-30]-[org.snmp4j.security.USM] RFC3414 §3.1.4.a 
Outgoing message needs to be encrypted
2014-10-22 10:42:33,427 DEBUG 
[http-0.0.0.0-8080-30]-[org.snmp4j.security.PrivDES] Preparing 
decrypt_params.
2014-10-22 10:42:33,427 DEBUG 
[http-0.0.0.0-8080-30]-[org.snmp4j.security.PrivDES] Preparing iv

Re: [SNMP4J] SNMPv3 problem with unhandled responses

2014-10-24 Thread Peter Verthez 
OK, thanks, we'll try that (we are on the latest version in our latest 
release, but the customer is using an older release of our product).


Best regards,
Peter.


On 24/10/2014 2:16, Frank Fock wrote:

Hi Peter,

Please update to the latest version. There have been several fixes 
about race conditions
in the Snmp class regarding retries and the PduHandleCallback. The 
current implementation
seems to be OK regarding handling of the Message IDs and the MPv3 
Cache WeakHashMap.


Best regards,
Frank

Am 23.10.2014 12:34, schrieb Peter Verthez:

Hi Frank,

One of our customers has reported a problem with SNMPv3.  The version 
of our application that they use is using SNMP4J 2.0.1. For the 
particular SNMP request that has the problem, the agent is known to 
respond very slowly, so the timeout model for that particular request 
has been set to:

- a first timeout after 30 seconds, then a retransmission
- a second timeout after 60 seconds (so 90 seconds after the original 
request), then a retransmission
- a third timeout after 120 seconds (210 seconds after the original 
request)


Now, we observe the following behavior (you can also see that in the 
logs that I'm pasting below):


2014-10-22 10:42:33,428 = Original request
2014-10-22 10:43:03,430 = 1st retransmission
2014-10-22 10:43:37,444 = Response to original request (rejected)
2014-10-22 10:44:03,440 = 2nd retransmission
2014-10-22 10:44:41,466 = Response to 1st retransmission (rejected)
2014-10-22 10:45:45,539 = Response to 2nd retransmission (accepted)

So the problem that we see is that the first response (the response 
to the original request) is not accepted for some reason.   This 
looks similar to the problem SFJ-43, but that was fixed in SNMP4J 
2.0.0 according to the change log.   We are in the process of trying 
to reproduce it on SNMP4J 2.3.0, but I see no relevant change in the 
change log, so I guess there will be no difference.


The logs are the following (with some sensitive information removed):


2014-10-22 10:42:33,426 DEBUG 
[http-0.0.0.0-8080-30]-[org.snmp4j.security.UsmUserTable] Adding user 
removed = UsmUser 
[secName=removed,authProtocol=1.3.6.1.6.3.10.1.1.3,authPassphrase=removed,privProtocol=1.3.6.1.6.3.10.1.2.2,privPassphrase=removed,localizationEngineID=null]
2014-10-22 10:42:33,427 DEBUG 
[http-0.0.0.0-8080-30]-[org.snmp4j.mp.MPv3] Context engine ID of 
scoped PDU is empty! Setting it to authoritative engine ID: 
80:00:02:7d:03:00:0e:86:1e:5f:9b
2014-10-22 10:42:33,427 DEBUG 
[http-0.0.0.0-8080-30]-[org.snmp4j.security.USM] getUser 
(engineID=80:00:02:7d:03:00:0e:86:1e:5f:9b, securityName=removed)
2014-10-22 10:42:33,427 DEBUG 
[http-0.0.0.0-8080-30]-[org.snmp4j.security.USM] RFC3414 §3.1.4.a 
Outgoing message needs to be encrypted
2014-10-22 10:42:33,427 DEBUG 
[http-0.0.0.0-8080-30]-[org.snmp4j.security.PrivDES] Preparing 
decrypt_params.
2014-10-22 10:42:33,427 DEBUG 
[http-0.0.0.0-8080-30]-[org.snmp4j.security.PrivDES] Preparing iv for 
encryption.
2014-10-22 10:42:33,427 DEBUG 
[http-0.0.0.0-8080-30]-[org.snmp4j.security.PrivDES] Using padding.
2014-10-22 10:42:33,427 DEBUG 
[http-0.0.0.0-8080-30]-[org.snmp4j.security.PrivDES] Encryption 
finished.
2014-10-22 10:42:33,427 DEBUG 
[http-0.0.0.0-8080-30]-[org.snmp4j.mp.MPv3] Adding cache entry: 
StateReference[msgID=1547681362,pduHandle=PduHandle[1912160112],securityEngineID=80:00:02:7d:03:00:0e:86:1e:5f:9b,securityModel=org.snmp4j.security.USM@897ec81,securityName=removed,securityLevel=3,contextEngineID=80:00:02:7d:03:00:0e:86:1e:5f:9b,contextName=nt,retryMsgIDs=null] 

2014-10-22 10:42:33,428 DEBUG 
[http-0.0.0.0-8080-30]-[org.snmp4j.Snmp] Running pending sync request 
with handle PduHandle[1912160112] and retry count left 2
2014-10-22 10:42:33,428 DEBUG 
[http-0.0.0.0-8080-30]-[org.snmp4j.transport.DefaultUdpTransportMapping] 
Sending message to 124.150.10.52/161 with length 143: 
30:81:8c:02:01:03:30:11:02:04:5c:3f:be:52:02:03:00:ff:ff:04:01:07:02:01:03:04:3a:30:38:04:0b:80:00:02:7d:03:
00:0e:86:1e:5f:9b:02:01:05:02:03:00:f6:1c:04:09:31:40:72:61:6c:65:69:67:68:04:0c:aa:82:4f:0d:79:70:ab:03:54:1d:8d:07:04:08: 

00:00:00:05:1a:64:0a:89:04:38:56:b3:24:74:26:e8:bc:d0:be:5c:f4:6e:59:d6:ac:2e:35:2d:01:fd:91:3f:be:0e:75:31:aa:96:4d:9b:36:ab:27:e7:65:e6:e3:18:55: 


a6:1a:fc:be:cc:22:3c:92:47:6a:06:3b:e7:30:1a:16:2c


2014-10-22 10:43:03,430 DEBUG [Timer-30]-[org.snmp4j.mp.MPv3] Adding 
cache entry: 
StateReference[msgID=1547681458,pduHandle=PduHandle[1912160112],securityEngineID=80:00:02:7d:03:00:0e:86:1e:5f:9b,securityModel=org.snmp4j.security.USM@897ec81,securityName=removed,securityLevel=3,contextEngineID=80:00:02:7d:03:00:0e:86:1e:5f:9b,contextName=nt,retryMsgIDs=null]
2014-10-22 10:43:03,430 DEBUG [Timer-30]-[org.snmp4j.Snmp] Running 
pending sync request with handle PduHandle[1912160112] and retry 
count left 1
2014-10-22 10:43:03,430 DEBUG 
[Timer-30]-[org.snmp4j.transport.DefaultUdpTransportMapping] Sending 
message

[SNMP4J] SNMPv3 problem with unhandled responses

2014-10-23 Thread Peter Verthez 
 information for the msgID could not 
be found
2014-10-22 10:44:41,467 WARN 
[DefaultUDPTransportMapping_124.150.10.20/0]-[org.snmp4j.MessageDispatcherImpl] 
statusInfo=noError, status=-1409



2014-10-22 10:45:45,539 DEBUG 
[DefaultUDPTransportMapping_124.150.10.20/0]-[org.snmp4j.transport.DefaultUdpTransportMapping] 
Received message from /124.150.10.52/161 with length 152:

30:82:00:94:02:01:03:30:11:02:04:5c:3f:bf:72:02:03:00:ff:ff:04:01:07:02:01:03:04:3a:30:38:04:0b:80:00:02:7d:03:00:0e:86:1e:5f:
9b:02:01:05:02:03:00:f6:dd:04:09:31:40:72:61:6c:65:69:67:68:04:0c:63:92:b3:32:2d:43:06:89:11:1b:bf:41:04:08:79:1a:79:1a:79:1a:
79:1a:04:40:3e:29:b5:5b:77:09:68:17:85:b1:9a:dc:22:75:cd:6d:f6:d7:3d:6f:a0:0c:6e:85:c5:9c:78:92:97:52:08:e6:83:59:5c:e9:70:44:
3c:5a:94:6e:f2:3a:f3:19:3e:fa:ba:6c:4f:3e:ed:32:2f:02:de:ce:c3:95:46:0c:79:c4
2014-10-22 10:45:45,539 DEBUG 
[DefaultUDPTransportMapping_124.150.10.20/0]-[org.snmp4j.mp.MPv3] SNMPv3 
header decoded: msgId=1547681650, msgMaxSize=65535, msgFlags=07, secModel=3
2014-10-22 10:45:45,540 DEBUG 
[DefaultUDPTransportMapping_124.150.10.20/0]-[org.snmp4j.security.USM] 
getUser(engineID=80:00:02:7d:03:00:0e:86:1e:5f:9b, securityName=removed)
2014-10-22 10:45:45,540 DEBUG 
[DefaultUDPTransportMapping_124.150.10.20/0]-[org.snmp4j.security.UsmTimeTable] 
CheckTime: time ok (non authoritative)
2014-10-22 10:45:45,540 DEBUG 
[DefaultUDPTransportMapping_124.150.10.20/0]-[org.snmp4j.mp.MPv3] 
Removed cache entry: 
StateReference[msgID=1547681650,pduHandle=PduHandle[1912160112],securityEngineID=80:00:02:7d:03:00:0e:86:1e:5f:9b,securityModel=org.snmp4j.security.USM@897ec81,securityName=removed,securityLevel=3,contextEngineID=80:00:02:7d:03:00:0e:86:1e:5f:9b,contextName=nt,retryMsgIDs=null]
2014-10-22 10:45:45,540 DEBUG 
[DefaultUDPTransportMapping_124.150.10.20/0]-[org.snmp4j.mp.MPv3] 
RFC3412 §7.2.10 - Received PDU (msgID=1547681650) is a response or an 
internal class message. PduHandle.transactionID = 1912160112
2014-10-22 10:45:45,540 DEBUG 
[DefaultUDPTransportMapping_124.150.10.20/0]-[org.snmp4j.mp.MPv3] MPv3 
finished
2014-10-22 10:45:45,540 DEBUG 
[DefaultUDPTransportMapping_124.150.10.20/0]-[org.snmp4j.Snmp] Looking 
up pending request with handle PduHandle[1912160112]
2014-10-22 10:45:45,540 DEBUG [http-0.0.0.0-8080-30]-[org.snmp4j.Snmp] 
Removed pending request with handle: PduHandle[1912160112]

--


As you can see, the first response is rejected with:
2014-10-22 10:43:37,444 DEBUG 
[DefaultUDPTransportMapping_124.150.10.20/0]-[org.snmp4j.mp.MPv3] 
RFC3412 §7.2.10 - Received PDU (msgID=1547681362) is a response or 
internal class message, but cached information for the msgID could not 
be found


However, I don't see a logging line telling that the entry for PDUHandle 
1912160112 has been removed from the MPv3 cache before that line.   I 
would expect:

- either the logging line from Cache.popEntry (Removed cache entry: ...)
- or the error line from Snmp.run, where Cache.deleteEntry is eventually 
called (Failed to send SNMP message to ...)


The entry is only explicitly removed at the very end, after the response 
to the second retransmission.


The only thing I can see (but I could be completely wrong about this) is 
that the MPv3 Cache uses a WeakHashMap, so if there would be no other 
references to those PduHandles, the GC could remove this.   The longer 
the timeout is, the bigger the chance that a GC will step in and remove 
the entry.   But I don't have a view on the overall design: maybe there 
are references elsewhere.


Could you investigate this issue?

Thanks,
Peter.

--
Peter Verthez
Systems Engineer Network Mgt.
Alcatel-Lucent Bell NV

___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j

Re: [SNMP4J] SnmpV3 Encryption Provider as Configurable parameter

2011-11-02 Thread Peter Verthez 
Hi Frank,

To elaborate on this (because the context wasn't really explained in the 
original mail of Jones):

We found that in performance tests on our product (with a big number of 
agents) that there was a high thread contention for SNMPv3 managed 
agents.   A jstack showed that a lot of our threads were running in the 
following stack frame at the moment of the jstack, which indicates that 
this functionality generates a relatively big load:

JM-282 prio=3 tid=0x00013f032800 nid=0x391 runnable 
[0xfffc89f38000]
java.lang.Thread.State: RUNNABLE
 at sun.security.pkcs11.wrapper.PKCS11.C_DestroyObject(Native Method)
 at sun.security.pkcs11.SessionKeyRef.dispose(P11Key.java:1070)
 at 
sun.security.pkcs11.SessionKeyRef.drainRefQueueBounded(P11Key.java:1046)
 at sun.security.pkcs11.SessionKeyRef.init(P11Key.java:1061)
 at sun.security.pkcs11.P11Key.init(P11Key.java:97)
 at sun.security.pkcs11.P11Key$P11SecretKey.init(P11Key.java:374)
 at sun.security.pkcs11.P11Key.secretKey(P11Key.java:266)
 at 
sun.security.pkcs11.P11SecretKeyFactory.createKey(P11SecretKeyFactory.java:222)
 at 
sun.security.pkcs11.P11SecretKeyFactory.convertKey(P11SecretKeyFactory.java:131)
 at sun.security.pkcs11.P11Cipher.engineGetKeySize(P11Cipher.java:828)
 at javax.crypto.Cipher.b(DashoA13*..)
 at javax.crypto.Cipher.a(DashoA13*..)
 at javax.crypto.Cipher.a(DashoA13*..)
 at javax.crypto.Cipher.a(DashoA13*..)
 - locked 0xfffd81aa1ca8 (a java.lang.Object)
 at javax.crypto.Cipher.init(DashoA13*..)
 at javax.crypto.Cipher.init(DashoA13*..)
 at org.snmp4j.security.PrivDES.encrypt(PrivDES.java:111)
 at org.snmp4j.security.USM.generateResponseMessage(USM.java:461)
 at org.snmp4j.security.USM.generateRequestMessage(USM.java:215)
 at org.snmp4j.mp.MPv3.prepareOutgoingMessage(MPv3.java:767)
 at 
org.snmp4j.MessageDispatcherImpl.sendPdu(MessageDispatcherImpl.java:444)
 at org.snmp4j.Snmp.sendMessage(Snmp.java:1067)
 at org.snmp4j.Snmp.send(Snmp.java:895)
 - locked 0xfffd81aa2068 (a org.snmp4j.Snmp$SyncResponseListener)
 at org.snmp4j.Snmp.send(Snmp.java:875)

Originally, our performance team pointed in the direction of SNMP4J, 
saying that SNMP4J should probably not call Cipher.init() so much, but I 
could show them that section 8.1.1.1 in RFC 2574 requires to init the 
Cipher for each packet separately.

So then we started looking at alternatives, and we found that if we 
hacked SNMP4J to use the Apache BouncyCastle security provider, the 
thread contention was gone and our application behaved properly.   So 
presumably the Sun JCE security provider that is used by default by 
SNMP4J is not very optimally written.

Now, we would not like to have to maintain our own patch on SNMP4J, so 
that is where the question from Jones came from: we tried to change the 
default security provider that SNMP4J uses without touching SNMP4J's 
code, but Security.insertProviderAt() apparently doesn't help in that 
even if we insert the provider at position 0.

Could an API be added to permit applications to change the security 
provider that SNMP4J uses?

Best regards,
Peter.


On 24/10/2011 9:00, jones vinu wrote:
 Hi Frank,
   We would want to change the Cipher encryption provider in our 
 application used by snmp4j since the Sun JCE provider is heavy weight . But 
 unfortunately we have not been able to change it without modifying snmp4j 
 since the Sun JCE provider is considered as the default provider even when we 
  insert Apache bouncy castle as the first priority provider. Hence it would 
 be good if we have option to configure the provider as a Configurable 
 parameter in some property file.

 Security.insertProviderAt(new BouncyCastleProvider(), 0);
  try {
  Cipher alg = Cipher.getInstance(DESede/CBC/NoPadding);
  System.out.println(alg.getProvider());
  } catch (NoSuchAlgorithmException e) {
  // TODO Auto-generated catch block
  e.printStackTrace();
  } catch (NoSuchPaddingException e) {
  // TODO Auto-generated catch block
  e.printStackTrace();
  }
 Output :SunJCE version 1.6

 And using it as
   Cipher alg = Cipher.getInstance(DESede/CBC/NoPadding,BC);
 Output :BC version 1.4

 Thanks
 Jones

 ___
 SNMP4J mailing list
 SNMP4J@agentpp.org
 http://lists.agentpp.org/mailman/listinfo/snmp4j


-- 
Peter Verthez
Systems Engineer Network Mgt.
Alcatel-Lucent Bell NV


___
SNMP4J mailing list
SNMP4J@agentpp.org
http://lists.agentpp.org/mailman/listinfo/snmp4j

[SNMP4J] SNMPv3 timing information

2010-06-17 Thread Peter Verthez 
Hello Frank,

I have a small question regarding SNMPv3 timing (engine boots, engine time).

We are managing an agent that does not behave entirely properly 
regarding this timing: in some cases it resets the engine time back to 
0, but without incrementing the engine boots.   What we see is that we 
as manager are then sending requests according to our knowledge of the 
engine boots/engine time, and these are - rightfully - rejected by the 
agent, because our engine time is higher than the agent's engine time.   
And the agent sends an SNMPv3 report with the usmStatsNotInTimeWindows 
variable.   This is never resolved, unless we force a cleanup in SNMP4J 
of the timing information for that agent.

Of course, the root cause (not incrementing the engine boots in the 
agent) is a bug in the agent, but there is a discussion going on in our 
team now what the proper behaviour of the manager should be.  The 
discussion is whether in such cases, since we are the non-authoritative 
engine in this exchange, the manager (and thus SNMP4J in this case) 
should automatically do a rediscovery of the engine boots/engine time.   
I couldn't immediately find an explanation in the RFCs to counter that 
argument, but it is clear that SNMP4J does not do that.

Could you explain your view on this?

Best regards,
Peter.

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

Alcatel-Lucent Bell NV
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.

___
SNMP4J mailing list
SNMP4J@agentpp.org
http://lists.agentpp.org/mailman/listinfo/snmp4j

Re: [SNMP4J] SNMPv3 timing information

2010-06-17 Thread Peter Verthez 
To follow up on my own question...

Verthez, Peter (Peter) wrote:
 Hello Frank,

 I have a small question regarding SNMPv3 timing (engine boots, engine time).

 We are managing an agent that does not behave entirely properly 
 regarding this timing: in some cases it resets the engine time back to 
 0, but without incrementing the engine boots.   What we see is that we 
 as manager are then sending requests according to our knowledge of the 
 engine boots/engine time, and these are - rightfully - rejected by the 
 agent, because our engine time is higher than the agent's engine time.   
 And the agent sends an SNMPv3 report with the usmStatsNotInTimeWindows 
 variable.   This is never resolved, unless we force a cleanup in SNMP4J 
 of the timing information for that agent.

 Of course, the root cause (not incrementing the engine boots in the 
 agent) is a bug in the agent, but there is a discussion going on in our 
 team now what the proper behaviour of the manager should be.  The 
 discussion is whether in such cases, since we are the non-authoritative 
 engine in this exchange, the manager (and thus SNMP4J in this case) 
 should automatically do a rediscovery of the engine boots/engine time.   
 I couldn't immediately find an explanation in the RFCs to counter that 
 argument, but it is clear that SNMP4J does not do that.
   

Well, I suppose what is applicable here is section 3.2 point 7b of RFC 
3414, but the question is: does this then also apply to the receiving of 
the report from the authoritative engine that says that the sent message 
is outside the time window?   It could be argued that in this case the 
manager should attempt to resynchronize with the agent.

Best regards,
Peter.

 Could you explain your view on this?

 Best regards,
 Peter.

   


-- 
Peter Verthez


___
SNMP4J mailing list
SNMP4J@agentpp.org
http://lists.agentpp.org/mailman/listinfo/snmp4j

[SNMP4J] Problem with timeout on SNMPv3 message

2009-12-09 Thread Peter Verthez 
]-[org.snmp4j.mp.MPv3]
RFC3412 §7.2.10 - Received PDU (msgID=543834129) is a response or
internal class message, but cached information for the msgID could not
be found
2009-12-09 15:20:30,912 WARN
[DefaultUDPTransportMapping_172.31.110.52/0]-[org.snmp4j.MessageDispatcherImpl] 

noError

Best regards,
Peter.

-- 
Peter Verthez
Systems Engineer Network Mgt.
Alcatel-Lucent Bell NV


___
SNMP4J mailing list
SNMP4J@agentpp.org
http://lists.agentpp.org/mailman/listinfo/snmp4j