Hi Alistair,

Thank you for reporting the NPE location. This is indeed
a regression bug. To fix it apply the following patch:

Index: UsmMIB.java
===================================================================
--- UsmMIB.java (revision 297)
+++ UsmMIB.java (working copy)
@@ -535,22 +535,26 @@
         AuthenticationProtocol a = getAuthProtocol(changeSet);
         if (a != null) {
           for (int p=0; p<2; p++) {
-            oldKeys[p] = new OctetString(getKey(oldUserEntry, p));
-            for (int i = 0; i < keyChangeColumns[p].length; i++) {
-              OctetString keyChange =
-                  (OctetString)getValue(keyChangeColumns[p][i]);
-              if ((keyChange != null) && (keyChange.length() > 0)) {
-                int keyLength = a.getDigestLength();
+            byte[] k = getKey(oldUserEntry, p);
+            oldKeys[p] = null;
+            if (k != null) {
+              oldKeys[p] = new OctetString(k);
+              for (int i = 0; i < keyChangeColumns[p].length; i++) {
+                OctetString keyChange =
+                    (OctetString)getValue(keyChangeColumns[p][i]);
+                if ((keyChange != null) && (keyChange.length() > 0)) {
+                  int keyLength = a.getDigestLength();

-                OctetString doKey = oldKeys[p];
-                if (p == 1) {
-                  // privacy protocol key change
- PrivacyProtocol privProtocol = getPrivProtocol(changeSet);
-                  keyLength = privProtocol.getMaxKeyLength();
+                  OctetString doKey = oldKeys[p];
+                  if (p == 1) {
+                    // privacy protocol key change
+ PrivacyProtocol privProtocol = getPrivProtocol(changeSet);
+                    keyLength = privProtocol.getMaxKeyLength();
+                  }
+                  newKeys[p] =
+                      KeyChange.changeKey(a, doKey, keyChange, keyLength);
+                  break; // only one key change per protocol
                 }
-                newKeys[p] =
-                    KeyChange.changeKey(a, doKey, keyChange, keyLength);
-                break; // only one key change per protocol
               }
             }
           }

Best regards,
Frank

Young, Alistair wrote:
Hi Frank.

In case you're interested, the NullPointerException occurs at line 538 of 
UsmMIB.java:

537: for (int p=0; p<2; p++) {
538:    oldKeys[p] = new OctetString(getKey(oldUserEntry, p));

On the second time around the loop, getKey returns null (because my user has no privacy password set) and so the OctetString constructor throws the NPE.
To trigger my serialisation, I've ended up adding a UsmUserListener:

public class Agent extends BaseAgent implements UsmUserListener {

   // ...

   public void init() {
      super.init();
      // ...
      this.getUsm().addUsmUserListener(this);
      this.finishInit();
   }

   public void usmUserChange(UsmUserEvent event) {
      this.saveConfig();
   }

}

Anyway, thanks for the tips - and for all your work on the SNMP4J library!

Cheers,


Alistair.

-----Original Message-----
From: Frank Fock [mailto:[email protected]] Sent: 23 March 2009 22:54
To: Young, Alistair
Cc: [email protected]
Subject: Re: [SNMP4J] Amending users

When you get a NullPointerException then something else seems to be 
misconfigured.

Yes, you can add a listener and save the config while the agent is running. I 
would use a MOServerLookupListener at the MOServer.

Frank


Young, Alistair wrote:
Thanks, Frank.

I tried removing the -xDES switch, but it still failed.  However, I noticed the 
agent throwing a NullPointerException and found that I could resolve this by 
ensuring that my user was given a privacy password even if it wasn't going to 
be used.

So everything now seems happy while the agent is running, and I can use snmpusm 
to change the user's password(s).

My next question is about serialising the change in password.  It appears that 
the user data gets written to the standard config file (agent.saveConfig()).  
Is it possible to force this serialisation to occur each time a password 
changes?  Perhaps I can add a listener to a particular MIB entry and trigger it 
that way?

Cheers,


Alistair.

-----Original Message-----
From: Frank Fock [mailto:[email protected]]
Sent: 23 March 2009 17:44
To: Young, Alistair
Cc: [email protected]
Subject: Re: [SNMP4J] Amending users

Hi Alistair,

Yes, you can add, remove, and change users through SNMP. However, you need an 
user with the same security level (i.e. authPriv) to do that. Since your user 
is only an authnoPriv user, you can only change the authentication password, 
but you did specify also -xDES which might have caused a problem.

Best regards,
Frank

Young, Alistair wrote:
Hello all,
Is it possible to dynamically amend user details in an SNMP4J agent? I have an Agent, overriding BaseAgent, which currently defines a single SNMP user: protected void addUsmUser(USM usm) {
   UsmUser user = new UsmUser
      new OctetString(username),
      AuthMD5.ID,
      new OctetString(password),
      null,
      null);
   usm.addUser(user.getSecurityName(), user); }
I can use this user quite happily to get/set values in my MIB tree. But, it is possible to dynamically change the user's password? I've tried using the snmpusm command line tool (from the net-snmp library) as
follows:
snmpusm -v3 -lauthNoPriv -xDES -aMD5 -A<password> -u<username>
192.168.10.10:16001 -Ca passwd <password> <newpassword> <username>
But this fails with:
Error in packet.
Reason: commitFailed
Failed object:
SNMP-USER-BASED-SM-MIB::usmUserAuthKeyChange."...p....*"."<username>"
Could I reasonably have expected this to work? Assuming that I can get this to work - does SNMP4J provide any direct support for obtaining the user details from a file? (So that I can remove the code which creates the user each time the agent starts). Thanks in advance for any help! Alistair.


Please help Logica to respect the environment by not printing this email  /  
Merci d'aider Logica à préserver l'environnement en évitant d'imprimer ce mail 
/  Bitte drucken Sie diese Nachricht nicht aus und helfen Sie so Logica dabei 
die Umwelt zu schuetzen  /  Por favor ajude a Logica a respeitar o ambiente não 
imprimindo este correio electrónico.



This e-mail and any attachment is for authorised use by the intended 
recipient(s) only. It may contain proprietary material, confidential 
information and/or be subject to legal privilege. It should not be copied, 
disclosed to, retained or used by, any other party. If you are not an intended 
recipient then please promptly delete this e-mail and any attachment and all 
copies and inform the sender. Thank you.

_______________________________________________
SNMP4J mailing list
[email protected]
http://lists.agentpp.org/mailman/listinfo/snmp4j


--
AGENT++
http://www.agentpp.com
http://www.mibexplorer.com
http://www.mibdesigner.com

_______________________________________________
SNMP4J mailing list
[email protected]
http://lists.agentpp.org/mailman/listinfo/snmp4j

Reply via email to