Re: [SNMP4J] trap error

2012-07-09 Thread Frank Fock 
Hi,

If the receivers are configured correctly, then the problem is the sender. The 
packet sizes should be identical.

Best regards,
Frank


dajiang hdaji...@rfnetech.com schrieb:

hi frank,

I don't quite understand why you said receiver is misconfigured. I 
used same command line setting for those two receivers 
(SnmpRequest.java). My hardware setting is: one device sends traps to 
two different destination computers.

I found your comments in one of the previous posts as follow:

For traps, the sender is authoritative. That is, each sender may use its 
own password for the same user name, because each sender MUST have a 
different engine ID (that's a plain SNMPv3 requirement).

In my case, I have only one sender but two receivers. Do I need to 
create two users at the same sender?

Another strange thing I've found from the debug print-out of snmp4j is 
that the packets size seem to be different at the two receivers. I am 
really lost at here.

Regards
dj




___
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] trap error

2012-07-08 Thread dajiang 
hi frank,

I don't quite understand why you said receiver is misconfigured. I 
used same command line setting for those two receivers 
(SnmpRequest.java). My hardware setting is: one device sends traps to 
two different destination computers.

I found your comments in one of the previous posts as follow:

For traps, the sender is authoritative. That is, each sender may use its 
own password for the same user name, because each sender MUST have a 
different engine ID (that's a plain SNMPv3 requirement).

In my case, I have only one sender but two receivers. Do I need to 
create two users at the same sender?

Another strange thing I've found from the debug print-out of snmp4j is 
that the packets size seem to be different at the two receivers. I am 
really lost at here.

Regards
dj




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

Re: [SNMP4J] trap error

2012-07-07 Thread Frank Fock 
Hi,

Most likely, the trap receiver is misconfigured. Note,
the trap sender is authoritative.

Best regards,
Frank

Am 07.07.2012 15:06, schrieb dajiang:
 Hi,

 I am using snmp4j to receive v3 traps from some devices. I've got a
 strange problem: the trap receiving shows different results in two
 different computers; in one computer, snmp4j is able to decode v3
 security info and show valid trap info; in another, it shows decoding error.

 The two computers run same OS: Windows Server 2008; and I installed same
 JDK (1.6). The snmp4j version is 2.0.2. I use
 org.snmp4j.tools.console.SnmpRequest to do the test; and the command
 line is :

 java -cp ..\lib\log4j-1.2.14.jar;. org.snmp4j.tools.console.SnmpRequest
 -u snmpadmin -a MD5 -A snmpadmin -x AES -X snmpadmin -Ol 0.0.0.0/162

 I run it in folder: snmp4j-2.0.2\classes.

 The output for the good result is:

 4758 [DefaultUDPTransportMapping_0.0.0.0/162] DEBUG
 org.snmp4j.transport.Default
 UdpTransportMapping  - Received message from /10.1.18.1/12151 with
 length 316: 3
 0:82:01:38:02:01:03:30:11:02:04:25:37:29:68:02:03:00:ff:e3:04:01:03:02:01:03:04:
 32:30:30:04:05:01:02:03:04:05:02:01:00:02:01:00:04:09:73:6e:6d:70:61:64:6d:69:6e
 :04:0c:d4:a7:41:86:53:8c:d3:e9:f7:87:6d:bd:04:08:73:bc:d0:8e:65:fd:15:dd:04:81:e
 b:d2:42:62:e6:7c:85:f5:53:4f:9c:8d:98:d6:bb:d5:11:0d:a6:5a:64:6d:4d:94:93:a5:fd:
 1d:7c:7e:c4:7c:b5:0a:12:15:14:0e:49:93:2f:58:5b:00:28:61:7a:23:50:ac:6c:81:ce:b8
 :e4:f5:4b:4c:ea:99:72:44:98:09:ea:0f:86:c0:58:e2:64:c7:7f:36:b6:a6:62:4a:a7:a7:c
 c:26:dd:05:ab:c5:c9:9a:87:a6:0b:51:bf:54:d0:50:fb:87:a6:a7:91:67:57:7a:e6:55:ca:
 7b:31:2c:0c:33:a1:19:35:bc:a7:c3:f3:dc:88:2b:70:85:e6:96:72:ac:50:ad:e1:35:25:04
 :7c:39:91:d9:dd:53:eb:67:19:34:4c:fe:79:36:de:bb:7e:7a:be:c3:86:9b:21:23:ee:07:5
 2:a1:87:d1:a5:e4:7e:a5:87:b8:30:20:0b:2c:66:24:0c:fa:55:52:83:d3:ea:da:a9:0f:7e:
 2a:1b:0d:b2:03:c9:6b:3d:64:3e:91:56:48:cf:43:8c:ea:56:84:63:18:d0:a4:f4:ed:a5:33
 :96:fa:78:c1:b9:aa:e1:1c:d0:ce:9b:ff:6e:45:25:6d:da:cc:e3:0a:77:1a
 4758 [DispatcherPool.1] DEBUG org.snmp4j.mp.MPv3  - SNMPv3 header
 decoded: msgId
 =624372071, msgMaxSize=65507, msgFlags=03, secModel=3
 5070 [DispatcherPool.0] DEBUG org.snmp4j.security.PrivAES  - aes
 decrypt: used k
 ey fa:10:64:e8:83:e7:01:b0:86:bb:cd:d4:8f:ea:23:c5
 5522 [DispatcherPool.0] DEBUG org.snmp4j.security.PrivAES  - aes
 decrypt: used p
 rivacy_params 73:bc:d0:8e:65:fd:15:db
 5460 [DispatcherPool.1] DEBUG org.snmp4j.security.USM  -
 getUser(engineID=01:02:
 03:04:05, securityName=snmpadmin)
 5585 [DispatcherPool.0] DEBUG org.snmp4j.security.PrivAES  - aes
 decrypt: decryp
 ted Data
 30:81:e8:04:05:01:02:03:04:05:04:00:a7:81:dc:02:04:7f:10:a2:aa:02:01:0
 0:02:01:00:30:81:cd:30:10:06:08:2b:06:01:02:01:01:03:00:43:04:01:28:f6:5b:30:18:
 06:0a:2b:06:01:06:03:01:01:04:01:00:06:0a:2b:06:01:04:01:d7:78:01:06:01:30:23:06
 :0c:2b:06:01:04:01:d7:78:01:05:01:01:01:04:13:32:30:31:32:2d:30:37:2d:30:37:20:3
 1:39:3a:34:34:3a:34:34:30:15:06:0c:2b:06:01:04:01:d7:78:01:05:01:01:02:04:05:70:
 6f:72:74:34:30:1a:06:0c:2b:06:01:04:01:d7:78:01:05:01:01:04:04:0a:31:30:2e:31:2e
 :31:38:2e:31:34:30:1b:06:0c:2b:06:01:04:01:d7:78:01:05:01:01:05:04:0b:31:30:2e:3
 2:36:2e:38:2e:31:39:33:30:2a:06:0c:2b:06:01:04:01:d7:78:01:05:01:01:0a:04:1a:49:
 43:4d:50:20:45:43:48:4f:20:70:61:79:6c:6f:61:64:20:6d:6f:64:69:66:69:65:64
 5647 [DispatcherPool.1] DEBUG org.snmp4j.security.UsmTimeTable  -
 CheckTime: tim
 e ok (non authoritative)
 5928 [DispatcherPool.0] DEBUG org.snmp4j.mp.MPv3  - RFC3412 ยบ7.2.10 -
 Received P
 DU is NOT a response or internal class message -  unchanged PduHandle =
 PduHandl
 e[2131796650]
 5990 [DispatcherPool.1] DEBUG org.snmp4j.security.PrivAES  - initVect is
 00:00:0
 0:00:00:00:00:00:73:bc:d0:8e:65:fd:15:dc
 6068 [DispatcherPool.0] DEBUG org.snmp4j.Snmp  - Fire process PDU event:
 Command
 ResponderEvent[securityModel=3, securityLevel=3,
 maxSizeResponsePDU=65370, pduHa
 ndle=PduHandle[2131796650], stateReference=null,
 pdu=TRAP[reqestID=2131796650, e
 rrorStatus=0, errorIndex=0, VBS[1.3.6.1.2.1.1.3.0 = 2 days, 6:03:37.23;
 1.3.6.1.
 6.3.1.1.4.1.0 = 1.3.6.1.4.1.11256.1.6.1; 1.3.6.1.4.1.11256.1.5.1.1.1 =
 2012-07-0
 7 19:44:44; 1.3.6.1.4.1.11256.1.5.1.1.2 = port4;
 1.3.6.1.4.1.11256.1.5.1.1.4 = 1
 0.1.18.14; 1.3.6.1.4.1.11256.1.5.1.1.5 = 10.26.8.193;
 1.3.6.1.4.1.11256.1.5.1.1.
 10 = ICMP ECHO payload modified]], messageProcessingModel=3,
 securityName=snmpad
 min, processed=false, peerAddress=10.1.18.1/12151,
 transportMapping=org.snmp4j.t
 ransport.DefaultUdpTransportMapping@276af2, tmStateReference=null]

 And output for the bad one:

 4352 [DefaultUDPTransportMapping_0.0.0.0/162] DEBUG
 org.snmp4j.transport.Default
 UdpTransportMapping  - Received message from /10.1.18.1/18322 with
 length 322: 3
 0:82:01:3e:02:01:03:30:11:02:04:25:37:24:cf:02:03:00:ff:e3:04:01:03:02:01:03:04:
 33:30:31:04:06:01:02:03:04:05:06:02:01:00:02:01:00:04:09:73:6e:6d:70:61:64:6d:69