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

[Jochen Katz]

Hi,

> Thanks, You should be able to see this in wireshark..its a
> rather large file - 17M

you should have applied a filter (e.g. udp) when capturing packets or
after capturing use a display filter (e.g. "ip.addr eq 1.2.3.4 and udp")
and then save the displayed packets only.

Packets 1447 1448 1500 1501 1502 and 1544 show a normal discovery.

I cannot say what happened inside the manager application between then
and packet 1734, but while engine time in packet 1544 is 20646, it is
83891 in packet 1734. So the USM throws away all reports and responses.

Before packet 16607, the time information in USM has been reset, so a
normal discovery process is done.

Does your application use the USMTimeTable class directly? snmp++ does
not reset the time information by itself and from the packet dumps, I
see no reason for the increased engine time.

Please enable logging for snmp++ in your application and set all log
levels to 15. Then check for logs of "USMTimeTable"

Regards,
  Jochen

> 
> 
> As per Snoop output, I see snmp++ did NOT behave as mentioned above (as
> per RFC2264).  You could also analyze the snoop output failed.pcap. I
> have summarized the behavior which is not as per the RFC.
> 1) Packet 1447: snmp++ started discovering USM variables. NE responded
> with a REPORT
> 2) Packet 1500: snmp++ used the USM variables it got from the NE, in the
> GET request. NE responded with a REPORT
> 3) Packet 1502: snmp++ used the USM variables it got from the NE, in the
> GET request. NE responded with a RESPONSE with GenErr.
> 4) Packet  1734: 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) Packet  16607 snmp++ started discovering USM variables AGAIN. NE
> responded with a REPORT
> 5a) step 2 and 3 are repeated here.
> 6) Packet 19672: 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 , 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.
>