[AGENT++] snmpv3 - question on usm use of engine_id , time window

[Jochen Katz]

Hi,

> For the above purpose we extract the engine_id by calling function
> v3MP::get_from_engine_id_table  , in case this function does not
> return success we call the second version of add_usm_user which does
> not require engine_id.
> 
> Is the above fallback recommended and is this approach to adding
> users with and without engine_id as a fallback recommended , if not 
> when should the function without engine_id  be used and safely too ?

your approach is OK. You only will have a problem, if the added user has
different passwords on the agents you want to get the engine id from. In
this case you will have to
1) add user with password of agentA
2) issue a request to agentA
3) add/replace user with password of agentB
4) issue a request to agentB

You can avoid this through creating a special Snmp object that you only
use for calling engine_id_discovery().

> Could the use of add_usm_user without engine_id create problems with
> key localization across multiple agents with same security profile ?

If "same security profile" is "same password, same auth and priv
protocols", then you won't have any problems. In fact, the intention
when creating the API was, that the add_user function without engine id
is the recommended function to use and snmp++ does the engine id
discovery process automatically. But as you already know, this only
works, if one user has the same password, auth and priv protocol on all
agents.

In an environment where a user has different profiles on the agents I
would recommend using the engine_id_discovery() function, but your
approach is also OK.

> 2. On another note we have another scenario where the the agent to
> which successful communication was established and worked fine until
>  a reboot of the agent occasionally throws the time window out of
> sync causing communication failure , in this case how can the v3
> manager resync and/or with regards time- window checking /timeliness
> checks ?

Normally the manager should automatically resynchronize to the agent
after the reboot. If this does not happen, most likely the agent has a
bug. The agent either:
a) resets the engine boot and engine time values to zero
b) does not increase the engine boot value

You could use Wireshark to check what applies and ask the author of the
agent to change this behaviour.

> Can the v3 function USM::remove_time_information be used for
> resetting internal time related state and thereby forcing a resync ?

Yes, this can be used as a workaround.

Regards,
  Jochen