[SNMP4J] Empty result when executing GETBULK operation to get single value.
Hi, I'm facing a problem when executing a walk operation to get a single value. I'm using snmp4j 2.0.2. I've tried with the main provided in jar but I've the same result. What am I doing wrong ? Here what I receive when I use the snmpwalk : lobj:$ snmpwalk -v 2c -c public 10.67.219.49 1.3.6.1.2.1.1.3.0 DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (363840427) 42 days, 2:40:04.27 If I execute the same operation with SnmpRequest.java, I receive this : lobj@:$ java -cp ../lib/snmp4j-2.0.2.jar:../lib/log4j-1.2.16.jar org.snmp4j.tools.console.SnmpRequest -Ow -c public -v 2c 10.67.219.49 1.3.6.1.2.1.1.3.0 0 [main] DEBUG org.snmp4j.security.Salt - Initialized Salt to 44c42b090a16e1a4. 26 [DefaultUDPTransportMapping_10.116.192.18/0] DEBUG org.snmp4j.transport.DefaultUdpTransportMapping - UDP receive buffer size for socket 10.116.192.18/0 is set to: 57344 55 [main] DEBUG org.snmp4j.Snmp - Running pending async request with handle PduHandle[898904463] and retry count left 1 68 [main] DEBUG org.snmp4j.transport.DefaultUdpTransportMapping - Sending message to 10.67.219.49/161 with length 43: 30:29:02:01:01:04:06:70:75:62:6c:69:63:a1:1c:02:04:35:94:31:8f:02:01:00:02:01:00:30:0e:30:0c:06:08:2b:06:01:02:01:01:03:00:05:00 101 [DefaultUDPTransportMapping_10.116.192.18/0] DEBUG org.snmp4j.transport.DefaultUdpTransportMapping - Received message from /10.67.219.49/161 with length 58: 30:38:02:01:01:04:06:70:75:62:6c:69:63:a2:2b:02:04:35:94:31:8f:02:01:00:02:01:00:30:1d:30:1b:06:08:2b:06:01:02:01:01:04:00:04:0f:4e:4f:43:2d:44:53:4c:2d:53:55:50:50:4f:52:54 120 [DefaultUDPTransportMapping_10.116.192.18/0] DEBUG org.snmp4j.Snmp - Looking up pending request with handle PduHandle[898904463] 123 [DefaultUDPTransportMapping_10.116.192.18/0] DEBUG org.snmp4j.Snmp - Cancelling pending request with handle PduHandle[898904463] Total requests sent:0 Total objects received: 0 Total walk time:101 milliseconds And if I execute again but with removing the last '0' at the end of OID : lobj@:$ java -cp ../lib/snmp4j-2.0.2.jar:../lib/log4j-1.2.16.jar org.snmp4j.tools.console.SnmpRequest -Ow -c public -v 2c 10.67.219.49 1.3.6.1.2.1.1.3 1 [main] DEBUG org.snmp4j.security.Salt - Initialized Salt to 75f59990912b2a82. 26 [DefaultUDPTransportMapping_10.116.192.18/0] DEBUG org.snmp4j.transport.DefaultUdpTransportMapping - UDP receive buffer size for socket 10.116.192.18/0 is set to: 57344 54 [main] DEBUG org.snmp4j.Snmp - Running pending async request with handle PduHandle[1118795335] and retry count left 1 57 [main] DEBUG org.snmp4j.transport.DefaultUdpTransportMapping - Sending message to 10.67.219.49/161 with length 42: 30:28:02:01:01:04:06:70:75:62:6c:69:63:a1:1b:02:04:42:af:76:47:02:01:00:02:01:00:30:0d:30:0b:06:07:2b:06:01:02:01:01:03:05:00 91 [DefaultUDPTransportMapping_10.116.192.18/0] DEBUG org.snmp4j.transport.DefaultUdpTransportMapping - Received message from /10.67.219.49/161 with length 47: 30:2d:02:01:01:04:06:70:75:62:6c:69:63:a2:20:02:04:42:af:76:47:02:01:00:02:01:00:30:12:30:10:06:08:2b:06:01:02:01:01:03:00:43:04:15:b0:70:68 113 [DefaultUDPTransportMapping_10.116.192.18/0] DEBUG org.snmp4j.Snmp - Looking up pending request with handle PduHandle[1118795335] 115 [DefaultUDPTransportMapping_10.116.192.18/0] DEBUG org.snmp4j.Snmp - Cancelling pending request with handle PduHandle[1118795335] 1.3.6.1.2.1.1.3.0 = 42 days, 2:47:26.48 166 [DefaultUDPTransportMapping_10.116.192.18/0] DEBUG org.snmp4j.Snmp - Running pending async request with handle PduHandle[1118795337] and retry count left 1 167 [DefaultUDPTransportMapping_10.116.192.18/0] DEBUG org.snmp4j.transport.DefaultUdpTransportMapping - Sending message to 10.67.219.49/161 with length 43: 30:29:02:01:01:04:06:70:75:62:6c:69:63:a1:1c:02:04:42:af:76:49:02:01:00:02:01:00:30:0e:30:0c:06:08:2b:06:01:02:01:01:03:00:05:00 209 [DefaultUDPTransportMapping_10.116.192.18/0] DEBUG org.snmp4j.transport.DefaultUdpTransportMapping - Received message from /10.67.219.49/161 with length 58: 30:38:02:01:01:04:06:70:75:62:6c:69:63:a2:2b:02:04:42:af:76:49:02:01:00:02:01:00:30:1d:30:1b:06:08:2b:06:01:02:01:01:04:00:04:0f:4e:4f:43:2d:44:53:4c:2d:53:55:50:50:4f:52:54 211 [DefaultUDPTransportMapping_10.116.192.18/0] DEBUG org.snmp4j.Snmp - Looking up pending request with handle PduHandle[1118795337] 211 [DefaultUDPTransportMapping_10.116.192.18/0] DEBUG org.snmp4j.Snmp - Cancelling pending request with handle PduHandle[1118795337] Total requests sent:1 Total objects received: 1 Total walk time:186 milliseconds Best regards Pierre ___ SNMP4J mailing list SNMP4J@agentpp.org http://lists.agentpp.org/mailman/listinfo/snmp4j
[SNMP4J] snmpv3 examples
hi I need snmpv3 examples Regards, Nadeesh TV ___ SNMP4J mailing list SNMP4J@agentpp.org http://lists.agentpp.org/mailman/listinfo/snmp4j
[SNMP4J] SnmpV3 timeout issue with system clock drift
Hi, We are encountering an issue with particular AMD processors in that the system clock drifts causing the snmpV3 requests to timeout after some point. Even once the clock gets resynched, the request will continue to timeout. Couple questions: 1) Initially, I would of expected a time not in window exception instead of a timeout? 2) If I do a discoverAuthoritativeEngineID after it timeouts, the requests starts working again. My question is it best practice to rediscover the engine ID on a timeout or exception? Or should I be looking at something else, such as clearing the usm time table? Thanks again for your help. Robert ___ SNMP4J mailing list SNMP4J@agentpp.org http://lists.agentpp.org/mailman/listinfo/snmp4j
Re: [SNMP4J] SnmpV3 timeout issue with system clock drift
Hi, Are you sure that the below is caused by a clock drift? A reset of the engine boots counter at the manager seems to be more likely. You are right, that a notInTimeWindow error/report should be returned if the times of sender and responder are not in sync. Doing an automated rediscovery is a security issue. Best regards, Frank On 03.11.2011 17:19, Robert Pierce wrote: Hi, We are encountering an issue with particular AMD processors in that the system clock drifts causing the snmpV3 requests to timeout after some point. Even once the clock gets resynched, the request will continue to timeout. Couple questions: 1) Initially, I would of expected a time not in window exception instead of a timeout? 2) If I do a discoverAuthoritativeEngineID after it timeouts, the requests starts working again. My question is it best practice to rediscover the engine ID on a timeout or exception? Or should I be looking at something else, such as clearing the usm time table? Thanks again for your help. Robert ___ SNMP4J mailing list SNMP4J@agentpp.org http://lists.agentpp.org/mailman/listinfo/snmp4j -- AGENT++ http://www.agentpp.com http://www.snmp4j.com http://www.mibexplorer.com http://www.mibdesigner.com ___ SNMP4J mailing list SNMP4J@agentpp.org http://lists.agentpp.org/mailman/listinfo/snmp4j
[SNMP4J] NullPointerException with snmp4j (Race condition bug?)
Hello, Sorry if you're getting this twice, I got an email the first time saying I'm not allowed to post. I thought I had signed up but apparently did not. I'm using the 2.0.2 version of snmp-4j I think a race condition exists in DefaultUdpTransportMapping() that leads to a NullPointerException: Here is the scenario : TransportMapping transport = new DefaultUdpTransportMapping(); transport.listen(); /* * set up all the pdu and target stuff here */ Snmp snmp = new Snmp(transport); snmp.send(pdu, cTarget); snmp.close(); Here is the exception that gets generated (on occassion) Exception in thread DefaultUDPTransportMapping_127.0.0.1/0 java.lang.NullPointerException at org.snmp4j.transport.DefaultUdpTransportMapping$ListenThread.run(DefaultUdpTransportMapping.java:321) at java.lang.Thread.run(Thread.java:662) Now, the reason I think this is a race condition is because it only happens occassionally when running my test. After looking through the code this is what I think is happening: - snmp.close() is calling the transport.close() which sets socket = null; -this happens before transport.listen() can start it's listening thread, but after it ensures the socket, so line 321 : socket.setSoTimeout() has a null socket object? Or am I just not using snmp4j correctly? Thanks ___ SNMP4J mailing list SNMP4J@agentpp.org http://lists.agentpp.org/mailman/listinfo/snmp4j
Re: [SNMP4J] Empty result when executing GETBULK operation to get single value.
Hi, First of all, NET-SNMP's snmpwalk and the SNMP GETBULK operation are two totally different things. GETRBULK is similar to GETNEXT. Thus if you provide an instance OID (ends with .0) you will not get the instance but its successor (if available). snmpwalk works very differently and it is not worth the time trying to compare it with GETBULK. Best regards, Frank Am 03.11.2011 10:06, schrieb pierre.coquen...@livingobjects.com: Hi, I'm facing a problem when executing a walk operation to get a single value. I'm using snmp4j 2.0.2. I've tried with the main provided in jar but I've the same result. What am I doing wrong ? Here what I receive when I use the snmpwalk : lobj:$ snmpwalk -v 2c -c public 10.67.219.49 1.3.6.1.2.1.1.3.0 DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (363840427) 42 days, 2:40:04.27 If I execute the same operation with SnmpRequest.java, I receive this : lobj@:$ java -cp ../lib/snmp4j-2.0.2.jar:../lib/log4j-1.2.16.jar org.snmp4j.tools.console.SnmpRequest -Ow -c public -v 2c 10.67.219.49 1.3.6.1.2.1.1.3.0 0 [main] DEBUG org.snmp4j.security.Salt - Initialized Salt to 44c42b090a16e1a4. 26 [DefaultUDPTransportMapping_10.116.192.18/0] DEBUG org.snmp4j.transport.DefaultUdpTransportMapping - UDP receive buffer size for socket 10.116.192.18/0 is set to: 57344 55 [main] DEBUG org.snmp4j.Snmp - Running pending async request with handle PduHandle[898904463] and retry count left 1 68 [main] DEBUG org.snmp4j.transport.DefaultUdpTransportMapping - Sending message to 10.67.219.49/161 with length 43: 30:29:02:01:01:04:06:70:75:62:6c:69:63:a1:1c:02:04:35:94:31:8f:02:01:00:02:01:00:30:0e:30:0c:06:08:2b:06:01:02:01:01:03:00:05:00 101 [DefaultUDPTransportMapping_10.116.192.18/0] DEBUG org.snmp4j.transport.DefaultUdpTransportMapping - Received message from /10.67.219.49/161 with length 58: 30:38:02:01:01:04:06:70:75:62:6c:69:63:a2:2b:02:04:35:94:31:8f:02:01:00:02:01:00:30:1d:30:1b:06:08:2b:06:01:02:01:01:04:00:04:0f:4e:4f:43:2d:44:53:4c:2d:53:55:50:50:4f:52:54 120 [DefaultUDPTransportMapping_10.116.192.18/0] DEBUG org.snmp4j.Snmp - Looking up pending request with handle PduHandle[898904463] 123 [DefaultUDPTransportMapping_10.116.192.18/0] DEBUG org.snmp4j.Snmp - Cancelling pending request with handle PduHandle[898904463] Total requests sent:0 Total objects received: 0 Total walk time:101 milliseconds And if I execute again but with removing the last '0' at the end of OID : lobj@:$ java -cp ../lib/snmp4j-2.0.2.jar:../lib/log4j-1.2.16.jar org.snmp4j.tools.console.SnmpRequest -Ow -c public -v 2c 10.67.219.49 1.3.6.1.2.1.1.3 1 [main] DEBUG org.snmp4j.security.Salt - Initialized Salt to 75f59990912b2a82. 26 [DefaultUDPTransportMapping_10.116.192.18/0] DEBUG org.snmp4j.transport.DefaultUdpTransportMapping - UDP receive buffer size for socket 10.116.192.18/0 is set to: 57344 54 [main] DEBUG org.snmp4j.Snmp - Running pending async request with handle PduHandle[1118795335] and retry count left 1 57 [main] DEBUG org.snmp4j.transport.DefaultUdpTransportMapping - Sending message to 10.67.219.49/161 with length 42: 30:28:02:01:01:04:06:70:75:62:6c:69:63:a1:1b:02:04:42:af:76:47:02:01:00:02:01:00:30:0d:30:0b:06:07:2b:06:01:02:01:01:03:05:00 91 [DefaultUDPTransportMapping_10.116.192.18/0] DEBUG org.snmp4j.transport.DefaultUdpTransportMapping - Received message from /10.67.219.49/161 with length 47: 30:2d:02:01:01:04:06:70:75:62:6c:69:63:a2:20:02:04:42:af:76:47:02:01:00:02:01:00:30:12:30:10:06:08:2b:06:01:02:01:01:03:00:43:04:15:b0:70:68 113 [DefaultUDPTransportMapping_10.116.192.18/0] DEBUG org.snmp4j.Snmp - Looking up pending request with handle PduHandle[1118795335] 115 [DefaultUDPTransportMapping_10.116.192.18/0] DEBUG org.snmp4j.Snmp - Cancelling pending request with handle PduHandle[1118795335] 1.3.6.1.2.1.1.3.0 = 42 days, 2:47:26.48 166 [DefaultUDPTransportMapping_10.116.192.18/0] DEBUG org.snmp4j.Snmp - Running pending async request with handle PduHandle[1118795337] and retry count left 1 167 [DefaultUDPTransportMapping_10.116.192.18/0] DEBUG org.snmp4j.transport.DefaultUdpTransportMapping - Sending message to 10.67.219.49/161 with length 43: 30:29:02:01:01:04:06:70:75:62:6c:69:63:a1:1c:02:04:42:af:76:49:02:01:00:02:01:00:30:0e:30:0c:06:08:2b:06:01:02:01:01:03:00:05:00 209 [DefaultUDPTransportMapping_10.116.192.18/0] DEBUG org.snmp4j.transport.DefaultUdpTransportMapping - Received message from /10.67.219.49/161 with length 58: 30:38:02:01:01:04:06:70:75:62:6c:69:63:a2:2b:02:04:42:af:76:49:02:01:00:02:01:00:30:1d:30:1b:06:08:2b:06:01:02:01:01:04:00:04:0f:4e:4f:43:2d:44:53:4c:2d:53:55:50:50:4f:52:54 211 [DefaultUDPTransportMapping_10.116.192.18/0] DEBUG org.snmp4j.Snmp - Looking up pending request with handle PduHandle[1118795337] 211 [DefaultUDPTransportMapping_10.116.192.18/0] DEBUG org.snmp4j.Snmp - Cancelling pending request with handle PduHandle[1118795337] Total requests sent:1 Total objects
Re: [SNMP4J] SnmpV3 Encryption Provider as Configurable parameter
Hi Peter,
I will try to add the requested configurability.
The ticket number is SFJ-52.
Best regards,
Frank
Am 02.11.2011 13:36, schrieb 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*..)
- locked0xfffd81aa1ca8 (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)
- locked0xfffd81aa2068 (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
___
SNMP4J mailing list
SNMP4J@agentpp.org
http://lists.agentpp.org/mailman/listinfo/snmp4j
[SNMP4J] snmpwalk
hi, as a utility are u supporting snmpwalk? can i get some sample code? ___ SNMP4J mailing list SNMP4J@agentpp.org http://lists.agentpp.org/mailman/listinfo/snmp4j
