[SNMP4J] Multiple Devices with the same Authoritative Engine ID

[Frank Fock]

Hi John,

Please see my answers inline below:

Am 03.04.2014 18:43, schrieb John Money:
> Hi Frank,
>
> Thank you for the great framework! I have been using snmp4j to communicate
> with several devices using v3 with authPriv. Recently, I came across a
> scenario where 10 of the devices I am querying have the same USM parameters
> (Security Name, Security Level, Auth Key and Priv Key) and I can see in the
> logs that they also have the same Authoritative Engine ID. This causes the
> snmp4j code to report the message "RFC3414 §3.2.7.a Not in time window"
> when one of the devices has a significantly different Engine Time than the
> others. I have the following questions:
>
> 1. Can the Authoritative Engine ID be the same for multiple devices
> according to the SNMP RFC?
No. The RFC explicitly defines algorithms to create unique 
(authoritative) engine IDs.
Having globally unique IDs is essential to SNMPv3!
>
> 2. Is the Authoritative Engine ID the same as the device Engine ID or is it
> a separate id altogether?
Basically, it is the same. The "authoritative" prefix marks one of the 
two engine IDs
involved in a point-to-point communication which is "authoritative". 
That engine
decides whether a SNMP command is processed or not.
>
> I have tried searching the web for these answers and I am not getting
> anything concrete. Also, I modified the snmp4j code to work around this
> issue by changing the Hash Key for the table variable in the UsmTimeTable
> class so that the new key is a combination of Device IP Address and
> Authoritative Engine Id. This allows each device to have its own Engine
> Time that is used for comparison and resolves the "Not in time window"
> issue. Two more questions:
>
> 3. Do you have any interest in adding this functionality to the snmp4j
> code? If so I can send the source to you.
No, because that "workaround" is not conforming to the SNMP standard.
>
> 4. I noticed that the comments for the UsmTimeTable class mention that it
> is a Singleton, yet the code is not setup as a singleton. Did you intend
> for this class to be a singleton or has that design decision changed and
> the comments just weren't updated?
 From the SNMP standard design it should be a singleton. However, 
applications
may want to have several SNMP entities within a single class loader. Thus,
it is not physically a singleton.

>
> Thank you for your time!
Your are welcome!

Best regards,
Frank

-- 
---
AGENT++
Maximilian-Kolbe-Str. 10
73257 Koengen, Germany
https://agentpp.com
Phone: +49 7024 8688230
Fax:   +49 7024 8688231