[SNMP4J] Wrong digest is a right digest

[chk-world at gmx.de]

Hi Frank,

thanks for your message.

> Of course, it could be a problem on the SNMP4J side, but I have also
> seen SNMP agents that have BER encoding flaws causing them to compute
> an incorrect digest.

Well, I never had problems with the agents with other NMSs before. So I
guess/hope the problem is not on the agent side (allready have the latest
firmware).

> In your case the problem is probably caused, because you  use several Snmp
> instances. By creating a Snmp instance a new MPv3 instance is added to
> the message dispatcher and a new USM instance replaces an existing USM
> in the security protocols singleton (which is bad).

So one thread is using or altering the USM of another thread? The USM uses a
different engine ID and therefor the digest is wrong? 
There is another side effect when creating a new SNMP instance for each
query: I first thought it would be a memory hole but then I found that there
are a lot of threads created which do not finish.

> I am currently changing the code so that existing security protocols 
> will not be
> changed by new Snmp instances. Until these changes can be made available,
> you can try to create all the Snmp instances before the threads are 
> started or to share a single Snmp instance.

> Another option would be to create an unique engine ID for each Snmp
> instance and to create a USM for each instance and subclass
> SecurityProtocols to add that new USM to it and then assign the each
> SecurityProtocols subclass instance to the MPv3 of each Snmp instance. 
> OK, this is a bit complicated so I do not recommend it ;-)

So I guess I'll have to wait for the 1.0.4c ;-)

Why doesn't anyone else got this problem with multiple agents? Does someone
have an idea of an usable or even proofed architecture of a management
application using snmp4j?

ciao,
Chris

-- 
Geschenkt: 3 Monate GMX ProMail + 3 Top-Spielfilme auf DVD
++ Jetzt kostenlos testen http://www.gmx.net/de/go/mail ++