<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://permalink.gmane.org/gmane.network.snmp4j.general">
    <title>gmane.network.snmp4j.general</title>
    <link>http://permalink.gmane.org/gmane.network.snmp4j.general</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.snmp4j.general/2244"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.snmp4j.general/2243"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.snmp4j.general/2242"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.snmp4j.general/2241"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.snmp4j.general/2240"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.snmp4j.general/2239"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.snmp4j.general/2238"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.snmp4j.general/2237"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.snmp4j.general/2236"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.snmp4j.general/2235"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.snmp4j.general/2234"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.snmp4j.general/2233"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.snmp4j.general/2232"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.snmp4j.general/2231"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.snmp4j.general/2230"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.snmp4j.general/2229"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.snmp4j.general/2228"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.snmp4j.general/2227"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.snmp4j.general/2226"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.snmp4j.general/2225"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://permalink.gmane.org/gmane.network.snmp4j.general/2244">
    <title>Re: V3 Not In Time Window and Client Clock Drift</title>
    <link>http://permalink.gmane.org/gmane.network.snmp4j.general/2244</link>
    <description>&lt;pre&gt;Hi Elise,
I agree, that the code should check case 1) first. I have not yet verified the current code but will do so tomorrow. If it needs to be changed (which seems to be true, according to your analysis). I will provide a path (new release until 31.5.2013).
Best regards,
Frank


Am 23.05.2013 um 17:52 schrieb Elise Atkins &amp;lt;eatkins-gwOx0t+qfa0AvxtiuMwx3w&amp;lt; at &amp;gt;public.gmane.org&amp;gt;:

&lt;/pre&gt;</description>
    <dc:creator>Frank Fock</dc:creator>
    <dc:date>2013-05-23T21:56:37</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.snmp4j.general/2243">
    <title>V3 Not In Time Window and Client Clock Drift</title>
    <link>http://permalink.gmane.org/gmane.network.snmp4j.general/2243</link>
    <description>&lt;pre&gt;We have been successfully using snmp4j using v3 for both requests and 
traps but have recently run into a problem with a client whose engine 
time clock runs slow.

Initial time synchronization  goes ok and the  SNMP v3 requests and 
responses flow properly.  Eventually this client's engine time becomes 
more 150 seconds behind the time SNMP4j is expecting and the responses 
are marked as Not In Time.  I have looked at RFC 2574 Section 3.2 
subsection 7b and the code in the UsmTimeTable class, checkTime method 
and have questions about the order of testing for timeliness.

Based on the RFC, I would expect the code to test for the conditions in 
1 first and update if needed before testing the conditions in 2 but the 
code seems to test in the reverse order. Testing 1 and updating reboots 
and time first will allow the client's clock to drift (fast or slow) as 
long as it is always increasing and remain in the time window. Am I 
missing something here?

Elise Atkins

The RFC says:

3.2.  Processing an Incoming&lt;/pre&gt;</description>
    <dc:creator>Elise Atkins</dc:creator>
    <dc:date>2013-05-23T15:52:07</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.snmp4j.general/2242">
    <title>Re: Is SHA-2 supported?</title>
    <link>http://permalink.gmane.org/gmane.network.snmp4j.general/2242</link>
    <description>&lt;pre&gt;Hi,

You can use only certain authentication protocols. However,
if you use (implement) a non-standard protocol for SNMPv3,
then you will have serious interoperability problems.
AFAIK, SHA-2 has not been yet defined for SNMPv3 by the
IETF.

If you want (very) secure authentication and a minimal interoperability,
then you can use TLS for SNMPv3.

Best regards,
Frank


Am 10.05.2013 23:27, schrieb Monika:

&lt;/pre&gt;</description>
    <dc:creator>Frank Fock</dc:creator>
    <dc:date>2013-05-16T20:58:07</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.snmp4j.general/2241">
    <title>Is SHA-2 supported?</title>
    <link>http://permalink.gmane.org/gmane.network.snmp4j.general/2241</link>
    <description>&lt;pre&gt;Hello,

www.snmp4j.org lists "SHA" as one of the supported 
authentication algorithms. Is this SHA-1, SHA-2 or both?
 Is it possible to restrict the usable algorithms to only the SAH-2 family and not 
allow SHA-1 and MD5 to be used? If so, how?


Thanks.
&lt;/pre&gt;</description>
    <dc:creator>Monika</dc:creator>
    <dc:date>2013-05-10T21:27:24</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.snmp4j.general/2240">
    <title>Re: Intercepting gets and sets from the Network Manager to individual cells in an MOTable</title>
    <link>http://permalink.gmane.org/gmane.network.snmp4j.general/2240</link>
    <description>&lt;pre&gt;Thanks Frank -- we ended up extending DefaultMOMutableRow2PC and all is working well.

I notice that there are several, or rather many, managed objects registered by default under your EnterpriseId = 4976.    Are these required by SNMP -- if yes, should we convert these to our enterprise id = 41485.  If no, can/should we suppress these?

Brad

-----Original Message-----
From: snmp4j-bounces-uhZIdBdo/7ZAfugRpC6u6w&amp;lt; at &amp;gt;public.gmane.org [mailto:snmp4j-bounces-uhZIdBdo/7ZAfugRpC6u6w&amp;lt; at &amp;gt;public.gmane.org] On Behalf Of Frank Fock
Sent: Thursday, April 04, 2013 4:45 PM
To: snmp4j-uhZIdBdo/7ZAfugRpC6u6w&amp;lt; at &amp;gt;public.gmane.org
Subject: Re: [SNMP4J] Intercepting gets and sets from the Network Manager to individual cells in an MOTable

Hi Brad,

You might want to read the SNMP4J-Agent instrumentation guide with more conceptual background and detailed examples:

http://www.snmp4j.org/SNMP4J-Agent-1.4-InstrumentationGuide.pdf

The most intuitive approach would be to override the http://www.snmp4j.org/agent/doc/org/snmp4j/agent/mo/Defa&lt;/pre&gt;</description>
    <dc:creator>Charan, Brad</dc:creator>
    <dc:date>2013-05-08T13:41:47</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.snmp4j.general/2239">
    <title>Fwd:  Fwd: Fwd: Table Model</title>
    <link>http://permalink.gmane.org/gmane.network.snmp4j.general/2239</link>
    <description>&lt;pre&gt;Hi Frank,

  Thank you very much for the clarifications. I think I am going to try to
solve the issue from another angle. As you know the callback function
queryEvent which is the  implementation  MOServerLookupListener class will
be called multiple times (when using getbulk), hence this will cause
issuing the same query to the DB every time the callback function is
executed.

I am going to update the table only when the DB table is updated, and I am
not going to implement MOServerLookupListener  interface.

The only concern I have is when the user sends getbulk request and this
will cause multiple requests being issued, in the meantime I need to update
the snmp table model because the db table is updated.

Do you think it is good approach to lock on the snmp table model for update
while the still processing getbulk? will this cause issues?

Regards
AF


---------- Forwarded message ----------
From: Frank Fock &amp;lt;fock-uhZIdBdo/7ZBDgjK7y7TUQ&amp;lt; at &amp;gt;public.gmane.org&amp;gt;
Date: Fri, May 3, 2013 at 5:47 PM
Subject: Re: [SNMP&lt;/pre&gt;</description>
    <dc:creator>Aiman Farhat</dc:creator>
    <dc:date>2013-05-07T14:41:20</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.snmp4j.general/2238">
    <title>Re: SNMP Buffer OverFlow Exception</title>
    <link>http://permalink.gmane.org/gmane.network.snmp4j.general/2238</link>
    <description>&lt;pre&gt;Hi,

That question has to be solved by yourself.

Best regards,
Frank

Am 03.05.2013 14:23, schrieb Ballarpure, Akshay (NSN - IN/Hyderabad):

&lt;/pre&gt;</description>
    <dc:creator>Frank Fock</dc:creator>
    <dc:date>2013-05-04T10:33:14</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.snmp4j.general/2237">
    <title>Re: Fwd:  Fwd: Table Model</title>
    <link>http://permalink.gmane.org/gmane.network.snmp4j.general/2237</link>
    <description>&lt;pre&gt;Hi Aiman,

Please reread my answer and then try to explain, why you
think that

"Which is not what I have expected as my model should have either Set1 or
Set2 but not mix of both."

should be true?

If you update the model with each incoming request and each request
can only return 1/3 of the table, then the first third of the resulting
table view in the browser will be from the Set1, the second third from
Set2, and the third from Set3.

This is exactly how it should work.

Best regards,
Frank

Am 03.05.2013 11:57, schrieb Aiman Farhat:

&lt;/pre&gt;</description>
    <dc:creator>Frank Fock</dc:creator>
    <dc:date>2013-05-03T16:47:10</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.snmp4j.general/2236">
    <title>Fwd:  Fwd: Table Model</title>
    <link>http://permalink.gmane.org/gmane.network.snmp4j.general/2236</link>
    <description>&lt;pre&gt;Hi Frank,

 Thanks for your response. According to instrumentation guide I am updating
the table model before the request is processed based on external event.
Our table will be small tables doesn't exceed 20 row max. The problem we
are having is not with the order, it is actually with the content. I have
a test data as follow:

Set1:
Component_set1_1
Component_set1_2
Component_set1_3

Set2:
Component_set2_1
Component_set2_2
Component_set2_3

When I send a request from a Mib browser, the table content gets mixed. For
example the data in the table could be something like that:

Component_set1_1
Component_set2_2
Component_set1_3

Which is not what I have expected as my model should have either Set1 or
Set2 but not mix of both.

As you know I am implementing MOServerLookupListener interface and in
queryEvent(MOServerLookupEvent event)  I am building my table model. I know
queryEvent method get called multiple times based on number of columns and
rows, and maybe that's why I am getting mixed results even though &lt;/pre&gt;</description>
    <dc:creator>Aiman Farhat</dc:creator>
    <dc:date>2013-05-03T09:57:22</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.snmp4j.general/2235">
    <title>Re: Fwd: Table Model</title>
    <link>http://permalink.gmane.org/gmane.network.snmp4j.general/2235</link>
    <description>&lt;pre&gt;Hi,

I think the table works perfectly. The ordering is correct.
(I know that this is not what you expected to hear ;-) )

OK, first some words on the background: As you might
already know, SNMP does not have a PDU or service
called "getTable". Instead you have GETNEXT and GETBULK
and an absolut upper limit of 64K per PDU (UDP).

Thus, medium and large tables will be never fetched with
a single Request-&amp;gt;Response communication. If you alter
your table for each request, the command generator
(= sender of the requests) will see "incosistent" data,
because you provided incosistent data.

Besides, it takes a lot CPU time, to recreate the table
for each request.

You can improve your code by updating the table only
every 2-5 seconds and not more often as a client would
typically need to fetch the whole table.

Best regards,
Frank




Am 02.05.2013 14:30, schrieb Aiman Farhat:

&lt;/pre&gt;</description>
    <dc:creator>Frank Fock</dc:creator>
    <dc:date>2013-05-02T15:28:44</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.snmp4j.general/2234">
    <title>Re: Fwd: Issue in SNMP set operation. Getting Error status 14 - commitFailed</title>
    <link>http://permalink.gmane.org/gmane.network.snmp4j.general/2234</link>
    <description>&lt;pre&gt;Hi Vasantharajan,

The error status 14 is returned by the agent. Thus, you will need
to consult the vendor/manufacturer to get information
of the possible cause.

Best regards,
Frank

Am 02.05.2013 15:55, schrieb vasanth:

&lt;/pre&gt;</description>
    <dc:creator>Frank Fock</dc:creator>
    <dc:date>2013-05-02T15:20:11</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.snmp4j.general/2233">
    <title>Re: SNMP Buffer OverFlow Exception</title>
    <link>http://permalink.gmane.org/gmane.network.snmp4j.general/2233</link>
    <description>&lt;pre&gt;Hi,

You probably misunderstood me. You do not need to synchronize anything,
just make sure that a PDU object is not modified after Snmp.send*
has been called. SNMP4J does not make an internal copy of the PDU
object for performance reasons. Thus, if you modify the object while
it is being send out, you get wrong results and BufferOverflowExceptions.

Best regards,
Frank

Am 02.05.2013 11:41, schrieb Ballarpure, Akshay (NSN - IN/Hyderabad):

&lt;/pre&gt;</description>
    <dc:creator>Frank Fock</dc:creator>
    <dc:date>2013-05-02T15:10:59</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.snmp4j.general/2232">
    <title>Fwd: Issue in SNMP set operation. Getting Error status 14- commitFailed</title>
    <link>http://permalink.gmane.org/gmane.network.snmp4j.general/2232</link>
    <description>&lt;pre&gt;Hi,

I am using SNMP4J API for SNMP set operation.

I tried to set the syslocation for the *ASR 9k device (SNMP V2)*. but set
operation is failed and getting error response.

Error Status: 14
Error Text: commitFailed&amp;lt;http://www.snmp4j.org/doc/org/snmp4j/PDU.html#commitFailed&amp;gt;

If i give the wrong credential, then i am getting the error response as"No
Access". But here i am trying with correct credentials only.

could you please help me here why i am getting
commitFailed&amp;lt;http://www.snmp4j.org/doc/org/snmp4j/PDU.html#commitFailed&amp;gt;
 error. In what scenario we will get this response.

Note: I am not facing this issue for other Cisco IOS devices.


Thanks,
Vasantharajan
&lt;/pre&gt;</description>
    <dc:creator>vasanth</dc:creator>
    <dc:date>2013-05-02T13:55:36</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.snmp4j.general/2231">
    <title>Fwd: Table Model</title>
    <link>http://permalink.gmane.org/gmane.network.snmp4j.general/2231</link>
    <description>&lt;pre&gt;Hi All,

The problem I am facing with snmp4j is as follow, I am building a
*dynamic*table model, where every time a request comes I clear the old
data and then
recreate it. The Issue I am facing is when I am sending subsequent requests
the data model is not returning the correct rows. Just to give you an
example:

As a test the data I am sending back to the request either:



Set A:

Component1

Component2

Component3

Component4

Component5

Component6


OR


Set B:

Component11

Component22

Component33

Component44

Component55

Component66



Now the problem as follow:

I see the following results in the Mib browser returned:

Component1

Component22

Component3

Component44

Component55

Component6


As you can see the values in the table model is not what I have expected.
As when I am building the table model I am clearing the old data then re
populated with either set A or Set B

of dummy values.



Just to elaborate more from code prospective :



T*his is building the table section:*



DefaultMOTab&lt;/pre&gt;</description>
    <dc:creator>Aiman Farhat</dc:creator>
    <dc:date>2013-05-02T12:30:10</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.snmp4j.general/2230">
    <title>Re: Why 'stop' on SocketException inDefaultUdpTransportMapping.ListenThread?</title>
    <link>http://permalink.gmane.org/gmane.network.snmp4j.general/2230</link>
    <description>&lt;pre&gt;Kelly,

Yes, the change wasn't a good one. It does not work if the exception is
thrown permantly, for example if the socket was closed (although
this should not happen). You can improve the behavior by
adding the following method to DefaultUdpTransportMapping:

   /**
    * If receiving new datagrams fails with a {&amp;lt; at &amp;gt;link SocketException}, 
this method is called to renew the
    * socket - if possible.
    * &amp;lt; at &amp;gt;param socketException
    *    the exception that occurred.
    * &amp;lt; at &amp;gt;return
    *    the new socket or &amp;lt;code&amp;gt;null&amp;lt;/code&amp;gt; if the listen thread should 
be terminated with the provided
    *    exception.
    * &amp;lt; at &amp;gt;throws SocketException
    *    a new socket exception if the socket could not be renewed.
    */
   protected DatagramSocket renewSocketAfterException(SocketException 
socketException) throws SocketException {
     DatagramSocket s = new DatagramSocket(udpAddress.getPort());
     s.setSoTimeout(socketTimeout);
     return s;
   }

Then change the DefaultUdpTransportMapping.ListenThread.run() method as&lt;/pre&gt;</description>
    <dc:creator>Frank Fock</dc:creator>
    <dc:date>2013-04-30T23:02:02</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.snmp4j.general/2229">
    <title>Re: SNMP Buffer OverFlow Exception</title>
    <link>http://permalink.gmane.org/gmane.network.snmp4j.general/2229</link>
    <description>&lt;pre&gt;Hello Akshay,

I think the root cause is the buffer overflow exception.
First, you should fix that issue.

Possible causes are:
1. The PDU or any contained VariableBinding is modified by another
thread (for example the PDU sender) after calling asynchronous
Snmp.send*.
2. A variable binding is being sent, that is not supported by the
protocol version (as you send a scoped pdu, I think this cases is not
matching your case).

Then you can optimize the threading behavior by reducing the
bootle neck in Snmp.NotificationDispatcher.processPdu by
replacing it with:

     public void processPdu(CommandResponderEvent event) {
       CommandResponder listener;
       synchronized (this) {
         listener = notificationTransports.get(event.getTransportMapping());
       }
       if ((event.getPDU() != null) &amp;amp;&amp;amp;
           (event.getPDU().getType() == PDU.INFORM)) {
         // try to send INFORM response
         try {
           sendInformResponse(event);
         }
         catch (MessageException mex) {
           &lt;/pre&gt;</description>
    <dc:creator>Frank Fock</dc:creator>
    <dc:date>2013-04-30T22:25:55</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.snmp4j.general/2228">
    <title>Why 'stop' on SocketException in DefaultUdpTransportMapping.ListenThread?</title>
    <link>http://permalink.gmane.org/gmane.network.snmp4j.general/2228</link>
    <description>&lt;pre&gt;I am a little confused by this change.  

We have run into this issue, with a sporadic socket closed exception, the cause of which we have not been able to identify.  What we are seeing is that the new behavior results in a busy-loop, since we go right back to a receive that is guaranteed to fail.  

This strikes me as a case where we need to either remediate the socket directly, or cancel the listener.  What am I missing?

Regards,
Kelly.


On 12.07.2011 14:02, Fock, Frank wrote:
&lt;/pre&gt;</description>
    <dc:creator>Kelly Dyer</dc:creator>
    <dc:date>2013-04-30T21:05:59</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.snmp4j.general/2227">
    <title>Re: SET access to created managed objects</title>
    <link>http://permalink.gmane.org/gmane.network.snmp4j.general/2227</link>
    <description>&lt;pre&gt;Frank, 

I have further ran through the code execution line by line and the
identified where the problem occurs - it is in VacmMIB.java class, in the
method getGroupName(...)

  private OctetString getGroupName(OctetString securityName,
                                   int securityModel) {
    OID index = new OID();
    index.append(securityModel);
    index.append(securityName.toSubIndex(false));
    MOTableRow row = vacmSecurityToGroupTableModel.getRow(index);
    if (row != null) {
      OctetString groupName = (OctetString) row.getValue(idxVacmGroupName);
      if (logger.isDebugEnabled()) {
        logger.debug("Found group name '"+groupName+"' for secName '"+
                     securityName+"' and secModel "+securityModel);
      }
      return groupName;
    }
    return null;
  }: 

For the private community, the call " MOTableRow row =
vacmSecurityToGroupTableModel.getRow(index);" returns a null "row", which
then propagates the error in a cascade. I tried to trace back this problem
through may f&lt;/pre&gt;</description>
    <dc:creator>Marek Hajduczenia</dc:creator>
    <dc:date>2013-04-29T08:34:42</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.snmp4j.general/2226">
    <title>Re: Cannot change the snmp password remotely</title>
    <link>http://permalink.gmane.org/gmane.network.snmp4j.general/2226</link>
    <description>&lt;pre&gt;Hi,

I guess you are mixing local and remote engine ID, but I am not sure.

Best regards,
Frank


Am 17.04.2013 13:58, schrieb Vilagut Abad, Roger:

&lt;/pre&gt;</description>
    <dc:creator>Frank Fock</dc:creator>
    <dc:date>2013-04-18T07:16:46</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.snmp4j.general/2225">
    <title>Cannot change the snmp password remotely</title>
    <link>http://permalink.gmane.org/gmane.network.snmp4j.general/2225</link>
    <description>&lt;pre&gt;Hello,

In order to remotely change the authentication password of a user I do the following steps:


1.       Get the usmUsrSpinLock.0 and save in sValue

2.       I obtain the old key of the user whose password I want to change as follows:
byte[] oldKey = snmp.getUSM().getUser(engineId, new OctetString(user)).getUsmUser().getAuthenticationPassphrase();

3.       Then I generate the new key as follows:

byte[] newKey = SecurityProtocols.getInstance().passwordToKey(AuthMD5.ID, new OctetString(newPassword), engineId.toByteArray());

4.       Then I generate the key change value as follows:

byte[] keyChange = new AuthMD5().changeDelta(oldKey, newKey, random.getBytes());

5.       And finally I do a SET to the usmUserTable:

SET(usmUserSpinLock.0=sValue, usmUserAuthKeyChange=keyChange, usmUserPublic=random)

When I read the usmUserTable MIB table after the SET I can see the random value in the usmUserPublic column, however when I do a request using the new password the agent responds that the password is not c&lt;/pre&gt;</description>
    <dc:creator>Vilagut Abad, Roger</dc:creator>
    <dc:date>2013-04-17T11:58:14</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.snmp4j.general/2224">
    <title>Re: Sending v1/2c Traps With Authentication</title>
    <link>http://permalink.gmane.org/gmane.network.snmp4j.general/2224</link>
    <description>&lt;pre&gt;Hi,

You have to specify the message processing model (aka. SNMP version) 
when sending
a PDU. That message processing model will be used - irrespective of the 
available
coexistance information.

Best regards,
Frank

Am 16.04.2013 16:40, schrieb m k:

&lt;/pre&gt;</description>
    <dc:creator>Frank Fock</dc:creator>
    <dc:date>2013-04-16T17:47:43</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.network.snmp4j.general">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.network.snmp4j.general</link>
  </textinput>
</rdf:RDF>
