[AGENT++] Wrong exeption in GET-response to unavailable object instance

[Frank Fock]

Hi Marcus,

OK, now I understand your question. The noSuchObject is returned,
because 1.3.6.1.2.1.1.1 is a scalar. Thus, 1.3.6.1.2.1.1.1.1 could not
potentially be an instance for 1.3.6.1.2.1.1.1 (sysDescr).  I think the
bottom line of the quoted paragraph of RFC 3416 is "potentially".

Do you agree?

Best regards,
Frank

Fehde, Marcus wrote:

>Hi Frank,
>
>Sorry I was imprecise and of course it was a noSuchObject exception. So again the question, why the agent do not response a noSuchInstance exception?
>
>-Marcus
>
>-----Original Message-----
>From: Frank Fock [mailto:fock at agentpp.com] 
>Sent: Freitag, 8. Oktober 2004 00:11
>To: Fehde, Marcus
>Cc: agentpp at agentpp.org
>Subject: Re: [AGENT++] Wrong exeption in GET-response to unavailable object instance
>
>
>Hi Marcus,
>
>There are only three exception states in SNMPv2c and SNMPv3: noSuchObject noSuchInstance endOfMibView
>
>With SNMPv1 all of the above exception states are mapped to the NO_SUCH_NAME error status. AGENT++ does not return the NO_SUCH_NAME error for SNMPv2c and SNMPv3 as you pointed out. Therefore I assume, that either you used SNMPv1 for the GET request or you used an AGENT++Win32 master agent in conjunction with a MS subagent DLL.
>
>Unfortunately, those DLLs do not return proper error codes.
>
>Hope this helps.
>
>Best regards,
>Frank
>
>Fehde, Marcus wrote:
>
>  
>
>>Hi,
>>
>>may be I discovered a non-compliance to RFC 3416 regarding the 
>>exception in case of an unavailable object instance.
>>Example:
>>An GET-request to 1.3.6.1.2.1.1.1.0 works as expected.
>>An GET-request to 1.3.6.1.2.1.1.1 result in a "no-such-name" exception as well as
>>an GET-requesz to 1.3.6.1.2.1.1.1.1.
>>
>>Accordingly to RFC3416 the correct result would be an 
>>"no-such-instance" exception:
>>
>>RFC3416 (SNMPv2); pp. 10-11 states:
>>"Upon receipt of a GetRequest-PDU, the receiving SNMP entity
>>processes each variable binding in the variable-binding list 
>>to produce a Response-PDU.  All fields of the Response-PDU 
>>have the same values as the corresponding fields of the 
>>received request except as indicated below.  Each variable 
>>binding is processed as follows:
>>  
>>...
>>  
>>(2)  Otherwise, if the variable binding's name does not have an
>> OBJECT IDENTIFIER prefix which exactly matches the OBJECT
>> IDENTIFIER prefix of any (potential) variable accessible by
>> this request, then its value field is set to "noSuchObject".
>>  
>> (3)  Otherwise, the variable binding's value field is set to  
>>"noSuchInstance".
>>
>>Please, can someone verify this.
>>
>>Best regards/Mit freundlichen Gruessen
>>
>>Marcus Fehde
>>Dipl. Ing. Technische Informatik (FH)
>>
>>Research & Development
>>Business Unit Anaesthesia 
>>_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
>>
>>DRÄGER MEDICAL
>>
>>Dräger Medical AG & Co. KGaA
>>Moislinger Allee 53-55 
>>D-23542 Lübeck 
>>
>>Tel:  + 49-451-882-3646
>>Fax: + 49-451-882-4410 
>>E-mail: marcus.fehde at draeger.com 
>>www.draeger-medical.com 
>>_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
>>
>>
>>
>> 
>>
>>-----------------------------------------------------------------------
>>-
>>
>>_______________________________________________
>>AGENTPP mailing list
>>AGENTPP at agentpp.org http://agentpp.org/mailman/listinfo/agentpp
>> 
>>
>>    
>>
>
>
>  
>
>------------------------------------------------------------------------
>
>_______________________________________________
>AGENTPP mailing list
>AGENTPP at agentpp.org
>http://agentpp.org/mailman/listinfo/agentpp
>  
>