[SNMP4J] FW: Difficulty with SNMP v3 Set
McCarthy, Peter CIV NAWCTSD, 4.6.2.3
peter.mccarthy at navy.mil
Thu Sep 5 14:41:43 CEST 2013
> Frank,
>
> Thank you for the response. I tried a few more experiments this
> morning. I ruled out problem #1 (access rights) as I was able to do
> gets and sets with a MIB browser application using the same
> credentials. That pointed me to problem #2.
>
> I found that if I read, then write things work every time. I'm
> attaching (does this work?) Wireshark captures of a scenario where
GET,
> then SET, then GET again. This results in four message pairs being
> sent, namely:
>
> 1a. Generic GET message
> 1b. Unknown engine response (1.3.6.1.6.3.15.1.1.4)
>
> 2a. First GET message. I noted that neither authoritative engine
> boots nor authoritative engine time are set on this outbound message.
> 2b. First GET response.
>
> 3a. SET message. Here, the engine boots and engine time are set
> properly.
> 3b. SET response.
>
> 4a. Second GET message. Here, again, the engine boots and engine
time
> are set properly.
> 4b. Second GET response.
>
> My working theory is that in my original example, the first message
was
> a SET without the time set properly. In this latest experiment, I
> think I worked around it by doing a GET first.
>
> Thanks for the pointers,
>
> Peter
>
> -----Original Message-----
> From: snmp4j-bounces at agentpp.org [mailto:snmp4j-bounces at agentpp.org]
On
> Behalf Of Frank Fock
> Sent: Wednesday, September 04, 2013 17:51
> To: snmp4j at agentpp.org
> Subject: Re: [SNMP4J] Difficulty with SNMP v3 Set
>
> Hello Peter,
>
> There could be two different reasons for your observation:
>
> 1. The agent uses different access rights for SET and GET PDUs which
> the user you are using does not equally have on the device.
> 2. The engine time synchronization fails for some reason.
>
> For the second case, using the latest SNMP4J version could help if the
> device (or the sender) has a very weak internal clock.
>
> The engine time can only be put in the sending request, if there was
> already some communication with the agent.
> If you create a new Snmp instance for each request then this happens
> all the time. Thus, you should reuse a single Snmp instance for all
the
> communication.
>
> Best regards,
> Frank
>
>
> Am 04.09.2013 19:46, schrieb McCarthy, Peter CIV NAWCTSD, 4.6.2.3:
> > Hello all,
> >
> > I'm having difficulty with sending SNMP v3 sets to a secured
(MD5/DES
> > such as it is) power strip. Code (largely taken from the get
example
> > in the documentation) is at the bottom:
> >
> > If I uncomment the GET STUFF section and comment out the SET STUFF
> > section, everything works and all the correct data is returned.
> >
> > If I uncomment the SET STUFF section and comment out the GET STUFF
> > section, no errors are returned. However, the setting is not placed
> > on the device (verified through the device's web interface).
> >
> > When I used Wireshark, I noticed on when a set message is sent,
> > neither the authoritative time nor boot count is placed in the
> > outgoing set request.
> >
> > Message flow, per Wireshark, looks like
> >
> > (1) Outbound, generic set or get message
> > (2) Inbound, 1.3.6.1.6.3.15.1.1.4 (unknown engine)
> > (3) Outbound, some encrypted PDU
> > (4) Inbound, response PDU
> >
> > Occasionally (rarely), there is another pair of messages between (2)
> > and (3), namely:
> >
> > (2a) Outbound, some encrypted PDU
> > (2b) Inbound, 1.3.6.1.6.3.15.1.1.2 (not in time window)
> >
> > If the "not in time window" appears, message (3) above will have
> > authoritative time and boot count populated.
> >
> > Am I doing something wrong here?
> >
> > Thanks,
> >
> > Peter...
> >
> > Address targetAddress =
> > GenericAddress.parse("udp:192.168.1.107/161");
> > TransportMapping transport = new
> DefaultUdpTransportMapping();
> > Snmp snmp = new Snmp(transport);
> > MPv3 mpv3 =
> > (MPv3)
> > snmp.getMessageProcessingModel(MessageProcessingModel.MPv3);
> > USM usm = new USM(SecurityProtocols.getInstance(),
> > new OctetString(mpv3.createLocalEngineID()), 0);
> > System.err.println("Enabled? " +
> > usm.isEngineDiscoveryEnabled());
> > SecurityModels.getInstance().addSecurityModel(usm);
> > transport.listen();
> >
> > // add user to the USM
> > snmp.getUSM().addUser(new OctetString("usernamehere"),
> > new UsmUser(new OctetString("usernamehere"),
> > AuthMD5.ID,
> > new OctetString("passwordhere"),
> > PrivDES.ID,
> > new OctetString("passwordhere")));
> > // create the target
> > UserTarget target = new UserTarget();
> > target.setAddress(targetAddress);
> > target.setRetries(1);
> > target.setTimeout(5000);
> > target.setVersion(SnmpConstants.version3);
> > target.setSecurityLevel(SecurityLevel.AUTH_PRIV);
> > target.setSecurityName(new OctetString("usernamehere "));
> >
> >
> > // GET STUFF
> > // PDU pdu = new ScopedPDU();
> > // pdu.add(new VariableBinding(new
> > OID("1.3.6.1.4.1.318.1.1.12.1.2.0")));
> > // pdu.add(new VariableBinding(new
> > OID("1.3.6.1.4.1.318.1.1.12.1.3.0")));
> > // pdu.add(new VariableBinding(new
> > OID("1.3.6.1.4.1.318.1.1.12.1.5.0")));
> > // pdu.add(new VariableBinding(new
> > OID("1.3.6.1.4.1.318.1.1.12.1.1.0")));
> > // pdu.add(new VariableBinding(new
> > OID("1.3.6.1.4.1.318.1.1.12.3.3.1.1.4.2")));
> > // pdu.add(new VariableBinding(new
> > OID("1.3.6.1.4.1.318.1.1.12.3.3.1.1.4.3")));
> > // pdu.add(new VariableBinding(new
> > OID("1.3.6.1.4.1.318.1.1.12.3.4.1.1.4.2")));
> > // pdu.setType(PDU.GET);
> >
> > // SET STUFF
> > PDU pdu = new ScopedPDU();
> > OID o1 = new OID("1.3.6.1.4.1.318.1.1.12.3.4.1.1.4.2");
> > Integer32 i32 = new Integer32(32);
> > pdu.add(new VariableBinding(o1, i32));
> > pdu.setType(PDU.SET);
> >
> > // send the PDU
> > ResponseEvent response = snmp.send(pdu, target);
> > // extract the response PDU (could be null if timed out)
> > PDU responsePDU = response.getResponse();
> > System.err.println("Error status: " +
> > responsePDU.getErrorStatus());
> > if(responsePDU != null) {
> > for (VariableBinding b :
> > responsePDU.getVariableBindings())
> > {
> > System.err.println(b.toString());
> >
> > }
> > }
> > _______________________________________________
> > SNMP4J mailing list
> > SNMP4J at agentpp.org
> > http://lists.agentpp.org/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 at agentpp.org
> http://lists.agentpp.org/mailman/listinfo/snmp4j
More information about the SNMP4J
mailing list