[AGENT++] Snmpv3 Get Failures - Snmp++ EngineID Discovery and USM msgAuthoritativeEngineTime

Anurag Jain anuragjain026 at hotmail.com
Fri Jan 14 02:13:56 CET 2011



On analysing packets of snmpv3  get failures .. we found the following (we are using  SNMP++v3.2.24 , we use it in engineid discovery mode )

1. snmp++ started discovering USM variables. remote agent/NE responded with a REPORT
2.snmp++ used the USM variables it got from the NE, in the GET request. NE responded with a REPORT
3.snmp ++used the USM variables it got from the NE, in the GET request. NE responded with a RESPONSE with GenErr.
4.snmp++ used the msgAuthoritativeEngineID and msgAuthoritativeEngineBoots it got from the NE, in the GET requ est. snmp ++DID NOT use the msgAuthoritativeEngineTime it got from the NE, in the GET request. NE responded with a REPORT.
5.snmp++ started discovering USM variables AGAIN. NE responded with a REPORT

6.snmp++ used the msgAuthoritativeEngineID and msgAuthoritativeEngineBoots it got from the NE, in the GET request. snmp++DID NOT use the msgAuthoritativeEngineTime it got from the NE, in the GET request. NE responded with a REPORT.

Referring to the steps mentioned for the failed snmp gets, I have following queries;
Query 1) Referring to step 4 and 6, why did not snmp++ use msgAuthoritativeEngineTime it got from NE in the GET request? Did genErr response from NE influenced snmp++ to behave so?
Query 2) Referring to step 2, why snmp ++tried 2nd time to discover the USM variables?
Query 3) Referring to step 5, why did snmp ++ started discovering the USM variables again? Was it because, NE responded with a REPORT for the previous request.

Can you please let us know the above is a known behavior/issue ?

Thanks
Anurag
 		 	   		  


More information about the AGENTPP mailing list