Re: [SNMP4J] Using localized keys
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
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
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
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