[SNMP4J] need suggestion..

[Wenchun (Jackie) Cheng]

Hi Frank,

Thank you for your response.

Yes, I noticed the addUser with engineID. 
"add on the fly" means add the user with the engineID. 
Since engineID is available at run-time and can be obtained from snmp
object.

To talk to an new snmp agnent, the process would be:
Discover the engineID of the agent, 
Add a user with that engineID to the USM
Create an user target
Send pdu

I thought of using 2 snmp objects in this case, one for group A and the
other one
for group B. 

If each snmp object is associated with one USM, the process would be:
Add the user to USM.
Create an user target.
Send pdu

In most case, if the user name is different, we don't need to worry about
the engineID.

But anyway, thanks for your suggestion. It's very helpful.

--Jackie
  

-----Original Message-----
From: Frank Fock [mailto:fock at agentpp.com] 
Sent: Tuesday, March 01, 2005 10:19 AM
To: wccheng at cisco.com
Cc: snmp4j at agentpp.org
Subject: Re: [SNMP4J] need suggestion..

Hi Jackie,

Wenchun (Jackie) Cheng wrote:

>Hi to all,
> 
>Suppose I am implementing a high performance SNMP monitor application 
>which usess snmp v3 to poll several devices. And the snmp v3 users on 
>the device may not be using the same auth/priv passphrases.
> 
>For example,
>on device group A,
>the user is "snmpuser" and the auth/priv passphrases are 
>"passauth"/"passpriv".
> 
>on device group B,
>the user is "snmpuser" and the auth/priv passphrases are 
>"authpass"/"privpass".
> 
>Since there is only one instance of SecurityModels to hold v3 user 
>model, it can only hold one generic (not associated with any 
>authoritiveEngineID) UsmUser with name "snmpuser". It seems like I can 
>only add v3 user on the
>  
>
Have you seen the addUser method in USM that takes the engineID too? See:
http://www.snmp4j.org/doc/org/snmp4j/security/USM.html#addUser(org.snmp4j.sm
i.OctetString,
org.snmp4j.smi.OctetString, org.snmp4j.security.UsmUser)

By adding each user specifically to each target's engine ID, it should be no
problem to access them.

>fly, which means add the user before sending any snmp packet to the target.
>  
>
Why should "adding on the fly" work if adding the user before would not?

>Other than this method, can anyone suggest what the best way (or 
>possible
>way) to implement the system?
>  
>
See above. The USM is not a singleton! It has a public constructor. However,
there exists a singleton registry for security models named SecurityModels
to facilitate security model access within a SNMP4J application. For most
use cases, this approach should be sufficient. If you need more than one
USM, you can subclass the SecurityModels class and provide a public
constructor and then set such a instance to your MPv3.

> 
>As a side question, what may be the reason to implement SecurityModels 
>as a singleton?
>  
>
As explained above, for most uses a singleton is best. If you need special
handling, then subclass it.

Hope this helps.

Best regards,
Frank