[AGENT++] Response to wrong snmpEngineId

[MFehde at t-online.de]

Hi Jochen,

our SNMP agent changes its engineId on each startup to an arbitrary one.

This enables us to detect the exchange of an entity without further
communication which is important for our application.
The SNMP manager is communicating with the agent and is not aware of the

exchange. This leads to the situation.
This would explain why the agent could be in discovery mode. On the
other hand I steped through the code and did not see any hint for being
in discovery mode.

Can you tell me whether we should get a timeout or a "unknownEngineId"
report?

Thanks for your help,
Marcus
-----Original Message-----
> Date: Sat,  3 Dec 2005 01:33:22 +0100
> Subject: Re: [AGENT++] Response to wrong snmpEngineId
> From: Jochen Katz 
> To: Agent++ Mailing List 

> Hi,
> 
> > Accordingly to RFC3414, ch. 3.2, 3) the agent should return a
> > REPORT-PDU containing the varbind usmUnknownEngineId.
> > As far as I've analyzed the code this does not happen. There are (at
> > least) two places where the engineId is checked.
> > One is in USM::process_msg where usm_time_table->check_time() is
> > called. Surprisingly for me, this method succeeds.
> > 
> 
> possibly the USM is in discovery mode, so it accepts all engine ids.
> But what I really want to know: Why does the manager send a message
> with a wrong engine id?
> 
> 
> > The second check of the engineId is done in v3MP::snmp_parse
> 
> > ...
> > if (!(unsignedCharCompare(securityEngineID.data(),
> securityEngineID.len(),
> > own_engine_id, own_engine_id_len))) {
> > debugprintf(0, "snmp_parse: securityEngineID doesn't match
> own_engine_id.");
> > usm->delete_sec_state_reference(securityStateReference);
> > return SNMPv3_MP_MATCH_ERROR;
> > ...
> 
> > But this check seems only to force the PDU to be discarded, but
> > without sending a REPORT.
> 
> This is because of rfc 3412 page 36/37:
> 13) If the pduType is from the Confirmed Class, then:
> 
> a) If the value of securityEngineID is not equal to the value of
> snmpEngineID, then the security state information is
> discarded, any cached information about this message is
> discarded, the incoming message is discarded without further
> processing, and a FAILURE result is returned.  SNMPv3 Message
> Processing is complete.
> 
> Looking at the USM rfc 3414 pages 27:
> 3)  If the value of the msgAuthoritativeEngineID field in the
> securityParameters is unknown then:
> 
> a) a non-authoritative SNMP engine that performs discovery may
> optionally create a new entry in its Local Configuration
> Datastore (LCD) and continue processing;
> 
> or
> 
> b) the usmStatsUnknownEngineIDs counter is incremented, and an
> error indication (unknownEngineID) together with the OID and
> value of the incremented counter is returned to the calling
> module.
> 
> Note in the event that a zero-length, or other illegally sized
> msgAuthoritativeEngineID is received, b) should be chosen to
> facilitate engineID discovery.  Otherwise the choice between a) and b)
> is an implementation issue.
> 
> The decission between a) and b) is impossible at this time because the
> entity does not know the pdu type and so cannot decide if the entity
> is authoritative or not. snmp++ currently uses only the flag
> discovery-mode to decide.
> 
> Regards,
> Jochen
> 
> _______________________________________________
> AGENTPP mailing list
> AGENTPP at agentpp.org
> http://lists.agentpp.org/mailman/listinfo/agentpp
>