Re: [SNMP4J] Using localized keys

2016-10-09 Thread Frank Fock

Hi Ron,

There are two cases you have to differentiate:

1. You have already localized passphrases for your target:
Then use USM.addLocalizedUser(...)
2. You have plain text passphrases for your target:
Then use USM.addUser with a UsmUser that had been created with a 
localizationEngineID.


In the second case, the passphrases will be localized by SNMP4J when the 
user is added to

the USM.

Hope this helps.

Best regards,
Frank

Am 09.10.2016 um 17:00 schrieb Ronald Braswell:

Hi,

I have read about localized keys and understand the concept.   I don't yet
understand how to implement them and use them with SNMP4J.

If anyone has the time to briefly share how to do this I would greatly
appreciate it.

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


--
---
AGENT++
Maximilian-Kolbe-Str. 10
73257 Koengen, Germany
https://agentpp.com
Phone: +49 7024 8688230
Fax:   +49 7024 8688231

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


[SNMP4J] Using localized keys

2016-10-09 Thread Ronald Braswell
Hi,

I have read about localized keys and understand the concept.   I don't yet
understand how to implement them and use them with SNMP4J.

If anyone has the time to briefly share how to do this I would greatly
appreciate it.

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


Re: [SNMP4J] Behaviour of ResponseListener in SNMP V3

2016-10-09 Thread Frank Fock

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.


2016-10-07 12:51:17,934 DEBUG 
[JM-4-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-07 12:51:17,950 DEBUG [JM-4-Ping-Ping-7]-[org.snmp4j.mp.MPv3] 
Context engine ID of scoped PDU is empty! Setting it to authoritative 
engine ID: 80:00:02:7d:03:00:90:d0:6d:fa:bc
2016-10-07 12:51:17,956 DEBUG 
[JM-4-Ping-Ping-7]-[org.snmp4j.security.USM] 
getUser(engineID=80:00:02:7d:03:00:90:d0:6d:fa:bc, 
securityName=verthezp_wrong2)
2016-10-07 12:51:17,964 DEBUG 
[JM-4-Ping-Ping-7]-[org.snmp4j.security.USM] RFC3414 §3.1.4.b 
Outgoing message is not encrypted
2016-10-07 12:51:17,965 DEBUG [JM-4-Ping-Ping-7]-[org.snmp4j.mp.MPv3] 
Adding cache entry: 
StateReference[msgID=46925,pduHandle=PduHandle[1444975050],securityEngineID=80:00:02:7d:03:00:90:d0:6d:fa:bc,securityModel=org.snmp4j.security.USM@529c7488,securityName=verthezp_wrong2,securityLevel=2,contextEngineID=80:00:02:7d:03:00:90:d0:6d:fa:bc,contextName=nt,retryMsgIDs=null]
2016-10-07 12:51:17,972 DEBUG [JM-4-Ping-Ping-7]-[org.snmp4j.Snmp] 
Running pending async request with handle PduHandle[1444975050] and 
retry count left 1
2016-10-07 12:51:17,973 DEBUG 
[JM-4-Ping-Ping-7]-[org.snmp4j.transport.DefaultUdpTransportMapping] 
Sending message to 135.249.41.7/161 with length 357: 
30:82:01:61:02:01:03:30:10:02:03:00:b7:4d:02:03:00:ff:ff:04:01:05:02:01:03:04:38:30:36:04:0b:80:00:02:7d:03:00:90:d0:6d:fa:bc:02:01:08:02:03:02:86:91:04:0f:76:65:72:74:68:65:7a:70:5f:77:72:6f:6e:67:32:04:0c:c2:71:d3:1c:34:43:4a:bb:b8:ba:b2:93:04:00:30:82:01:0e:04:0b:80:00:02:7d:03:00:90:d0:6d:fa:bc:04:02:6e:74:a0:81:fa:02:04:56:20:91:ca: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-10-07 12:51:18,125 DEBUG 
[DefaultUDPTransportMapping_172.31.109.98/0]-[org.snmp4j.transport.DefaultUdpTransportMapping] 
Received message from /135.249.41.7/161 with length 103: 
30:65:02:01:03:30:10:02:03:00:b7:4d:02:03:00:ff:ff:04:01:00:02:01:03:04:1d:30:1b:04:0b:80:00:02:7d:03:00:90:d0:6d:fa:bc:02:01:08:02:03:02:86:92:04:00:04:00:04:00:30:2f:04:0b:80:00:02:7d:03:00:90:d0:6d:fa:bc:04:02:6e:74:a8:1c:02:01:00:02:01:00:02:01:00:30:11:30:0f:06:0a:2b:06:01:06:03:0f:01:01:03:00:41:01:44
2016-10-07 12:51:18,125 DEBUG 
[DefaultUDPTransportMapping_172.31.109.98/0]-[org.snmp4j.mp.MPv3] 
SNMPv3 header decoded: msgId=46925, msgMaxSize=65535, msgFlags=00, 
secModel=3
2016-10-07 12:51:18,126 DEBUG 
[DefaultUDPTransportMapping_172.31.109.98/0]-[org.snmp4j.security.USM] Accepting 
zero length security 

Re: [SNMP4J] Behaviour of ResponseListener in SNMP V3

2016-10-09 Thread 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.


2016-10-07 12:51:17,934 DEBUG 
[JM-4-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-07 12:51:17,950 DEBUG [JM-4-Ping-Ping-7]-[org.snmp4j.mp.MPv3] 
Context engine ID of scoped PDU is empty! Setting it to authoritative 
engine ID: 80:00:02:7d:03:00:90:d0:6d:fa:bc
2016-10-07 12:51:17,956 DEBUG 
[JM-4-Ping-Ping-7]-[org.snmp4j.security.USM] 
getUser(engineID=80:00:02:7d:03:00:90:d0:6d:fa:bc, 
securityName=verthezp_wrong2)
2016-10-07 12:51:17,964 DEBUG 
[JM-4-Ping-Ping-7]-[org.snmp4j.security.USM] RFC3414 §3.1.4.b Outgoing 
message is not encrypted
2016-10-07 12:51:17,965 DEBUG [JM-4-Ping-Ping-7]-[org.snmp4j.mp.MPv3] 
Adding cache entry: 
StateReference[msgID=46925,pduHandle=PduHandle[1444975050],securityEngineID=80:00:02:7d:03:00:90:d0:6d:fa:bc,securityModel=org.snmp4j.security.USM@529c7488,securityName=verthezp_wrong2,securityLevel=2,contextEngineID=80:00:02:7d:03:00:90:d0:6d:fa:bc,contextName=nt,retryMsgIDs=null]
2016-10-07 12:51:17,972 DEBUG [JM-4-Ping-Ping-7]-[org.snmp4j.Snmp] 
Running pending async request with handle PduHandle[1444975050] and 
retry count left 1
2016-10-07 12:51:17,973 DEBUG 
[JM-4-Ping-Ping-7]-[org.snmp4j.transport.DefaultUdpTransportMapping] 
Sending message to 135.249.41.7/161 with length 357: 
30:82:01:61:02:01:03:30:10:02:03:00:b7:4d:02:03:00:ff:ff:04:01:05:02:01:03:04:38:30:36:04:0b:80:00:02:7d:03:00:90:d0:6d:fa:bc:02:01:08:02:03:02:86:91:04:0f:76:65:72:74:68:65:7a:70:5f:77:72:6f:6e:67:32:04:0c:c2:71:d3:1c:34:43:4a:bb:b8:ba:b2:93:04:00:30:82:01:0e:04:0b:80:00:02:7d:03:00:90:d0:6d:fa:bc:04:02:6e:74:a0:81:fa:02:04:56:20:91:ca: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-10-07 12:51:18,125 DEBUG 
[DefaultUDPTransportMapping_172.31.109.98/0]-[org.snmp4j.transport.DefaultUdpTransportMapping] 
Received message from /135.249.41.7/161 with length 103: 
30:65:02:01:03:30:10:02:03:00:b7:4d:02:03:00:ff:ff:04:01:00:02:01:03:04:1d:30:1b:04:0b:80:00:02:7d:03:00:90:d0:6d:fa:bc:02:01:08:02:03:02:86:92:04:00:04:00:04:00:30:2f:04:0b:80:00:02:7d:03:00:90:d0:6d:fa:bc:04:02:6e:74:a8:1c:02:01:00:02:01:00:02:01:00:30:11:30:0f:06:0a:2b:06:01:06:03:0f:01:01:03:00:41:01:44
2016-10-07 12:51:18,125 DEBUG 
[DefaultUDPTransportMapping_172.31.109.98/0]-[org.snmp4j.mp.MPv3] 
SNMPv3 header decoded: msgId=46925, msgMaxSize=65535, msgFlags=00, 
secModel=3
2016-10-07 12:51:18,126 DEBUG 
[DefaultUDPTransportMapping_172.31.109.98/0]-[org.snmp4j.security.USM] 
Accepting zero length security name
2016-10-07 12:51:18,126 DEBUG 
[DefaultUDPTransportMapping_172.31.109.98/0]-[org.snmp4j.mp.MPv3] 
Removed cache entry: 
StateReference[msgID=46925,pduHandle=PduHandle[1444975050],securityEngineID=80:00:02:7d:03:00:90:d0:6d:fa:bc,securityModel=org.snmp4j.security.USM@529c7488,securityName=verthezp_wrong2,securityLevel=2,contextEngineID=80:00:02:7d:03:00:90:d0:6d:fa:bc,contextName=nt,retryMsgIDs=null]
2016-10-07 12:51:18,126 DEBUG 
[DefaultUDPTransportMapping_172.31.109.98/0]-[org.snmp4j.mp.MPv3] 
RFC3412 §7.2.10 - Received PDU (msgID=46925) is a response or an 
internal class message. PduHandle.transactionID = 1444975050
2016-10-07 12:51:18,126 DEBUG 
[DefaultUDPTransportMapping_172.31.109.98/0]-[org.snmp4j.mp.MPv3] MPv3 
finished
2016-10-07 12:51:18,126 DEBUG 
[DefaultUDPTransportMapping_172.31.109.98/0]-[org.snmp4j.Snmp] 
Searching pending request with handlePduHandle[1444975050]
2016-10-07 12:51:18,128 INFO 
[DefaultUDPTransportMapping_172.31.109.98/0]-[org.snmp4j.Snmp] 
Received late report from 135.249.41.7/161 with request ID 0