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

[Anurag Jain]

Apologize about the large file size.

No we do not use the USMTimeTable directly. We use the add_usm_user like below to setup usm with or without the engineID based on availability of engineID.

             status=v3P->get_from_engine_id_table(engineID,ipAddr.get_printable());
        if(status==SNMPv3_MP_OK && engineID.len() > 0){

            v3P->get_usm()->add_usm_user(OctetStr(securityUser.c_str()),
                                         OctetStr(securityUser.c_str()),
                                         authProtocol,
                                         privProtocol,
                                         OctetStr(authPassword.c_str
                                         OctetStr(privPassword.c_str()),
                                         engineID);
             }else
                       v3P->get_usm()->add_usm_user(OctetStr(securityUser.c_str()),
                                             authProtocol,
                                             privProtocol,
                                             OctetStr(authPassword.c_str()),
                                             OctetStr(privPassword.c_str()));
          }

I can get back with logs but in the meantime let me know if there are any other comments.


Thanks
Anurag

> Date: Tue, 18 Jan 2011 22:53:38 +0100
> From: katz at agentpp.com
> To: agentpp at agentpp.org
> Subject: Re: [AGENT++] Snmpv3 Get Failures - Snmp++ EngineID Discovery and USM msgAuthoritativeEngineTime
> 
> 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.
> > 
> _______________________________________________
> AGENTPP mailing list
> AGENTPP at agentpp.org
> http://lists.agentpp.org/mailman/listinfo/agentpp