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

[Fehde, Marcus]

Hi Frank,

I'm not really convinced. The 1.3.6.1.2.1.1.1 (sysDescr) as well as the 1.3.6.1.2.1.1.1.1 (sysDescr.1) containing valid matching prefixes to sysDescr. The first one matches with the object it self (w/o instance) and the later matches also and could access another instance than 0. Of course this is not allowed for a scalar object, but nevertheless the SNMP protocol does not distinguish between scalar and (conceptual) columnar and hence the appropriate reaction should be noSuchInstance.
I would agree if I had requested 1.3.6.1.2.1.1 which is no matching prefix to any object.

Regards,
Marcus

-----Original Message-----
From: Frank Fock [mailto:fock at agentpp.com] 
Sent: Freitag, 8. Oktober 2004 09:35
To: Fehde, Marcus
Cc: Agent++ Mailing List
Subject: Re: [AGENT++] Wrong exeption in GET-response to unavailable object instance


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
>  
>


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: InterScan_Disclaimer.txt
Url: http://lists.agentpp.org/pipermail/agentpp/attachments/20041008/0d32a605/attachment.txt