[SNMP4J] SNMP4J Digest, Vol 90, Issue 11

Frank Fock fock at agentpp.com
Tue Jul 22 00:54:44 CEST 2014


Hi Harsha,

RC 1905 has been obsoleted by RFC 3416.
Besides the paragraphs you quoted, also the following are important:

-- BEGIN-QUOTE
   If N is greater than zero, the first through the (N)-th variable
    bindings of the Response-PDU are each produced as follows:

    (1)   The variable is located which is in the lexicographically
          ordered list of the names of all variables which are accessible
          by this request and whose name is the first lexicographic
          successor of the variable binding's name in the incoming
          GetBulkRequest-PDU.  The corresponding variable binding's name
          and value fields in the Response-PDU are set to the name and
          value of the located variable.

    (2)   If the requested variable binding's name does not
          lexicographically precede the name of any variable accessible
          by this request, i.e., there is no lexicographic successor,
          then the corresponding variable binding produced in the
          Response-PDU has its value field set to "endOfMibView", and its
          name field set to the variable binding's name in the request.

    If M and R are non-zero, the (N + 1)-th and subsequent variable
    bindings of the Response-PDU are each produced in a similar manner.
    For each iteration i, such that i is greater than zero and less than
    or equal to M, and for each repeated variable, r, such that r is
    greater than zero and less than or equal to R, the (N + ( (i-1) * R )
    + r)-th variable binding of the Response-PDU is produced as follows:

Presuhn, et al.             Standards Track                    [Page 15]

RFC 3416              Protocol Operations for SNMP         December 2002


    (1)   The variable which is in the lexicographically ordered list of
          the names of all variables which are accessible by this request
          and whose name is the (i)-th lexicographic successor of the (N
          + r)-th variable binding's name in the incoming
          GetBulkRequest-PDU is located and the variable binding's name
          and value fields are set to the name and value of the located
          variable.

    (2)   If there is no (i)-th lexicographic successor, then the
          corresponding variable binding produced in the Response-PDU has
          its value field set to "endOfMibView", and its name field set
          to either the last lexicographic successor, or if there are no
          lexicographic successors, to the (N + r)-th variable binding's
          name in the request.

    While the maximum number of variable bindings in the Response-PDU is
    bounded by N + (M * R), the response may be generated with a lesser
    number of variable bindings (possibly zero) for either of three
    reasons.

    (1)   If the size of the message encapsulating the Response-PDU
          containing the requested number of variable bindings would be
          greater than either a local constraint or the maximum message
          size of the originator, then the response is generated with a
          lesser number of variable bindings.  This lesser number is the
          ordered set of variable bindings with some of the variable
          bindings at the end of the set removed, such that the size of
          the message encapsulating the Response-PDU is approximately
          equal to but no greater than either a local constraint or the
          maximum message size of the originator.  Note that the number
          of variable bindings removed has no relationship to the values
          of N, M, or R.

    (2)   The response may also be generated with a lesser number of
          variable bindings if for some value of iteration i, such that i
          is greater than zero and less than or equal to M, that all of
          the generated variable bindings have the value field set to
          "endOfMibView".  In this case, the variable bindings may be
          truncated after the (N + (i * R))-th variable binding.

    (3)   In the event that the processing of a request with many
          repetitions requires a significantly greater amount of
          processing time than a normal request, then a command responder
          application may terminate the request with less than the full
          number of repetitions, providing at least one repetition is
          completed.
-- END QUOTE

The second to last parapgraph requires that full iterations for the repeated
names have to be returned. Your agent does not seem to return not full
iterations if I assume that there were two repeater names given in the 
request.

If there was a single name given, than the agent simply does not handle
lexicographic ordering correctly.

To be sure, you will have to provide the hex-dump of the request PDU and
the response PDU.

Best rergards,
Frank

Am 21.07.2014 13:04, schrieb Harsha H R:
> Hi Frank,
>
> I'm not clear on what is the bug here!
>
> Below is the extract from RFC 1905(Protocol Operations
>                            for Version 2 of the
>                Simple Network Management Protocol (SNMPv2)
>
> On page number 15
>
> (2)  If the requested variable binding's name does not lexicographically
>       precede the name of any variable accessible by this request, i.e.,
>       there is no lexicographic successor, then the corresponding
>       variable binding produced in the Response-PDU has its value field
>       set to `endOfMibView', and its name field set to the variable
>       binding's name in the request.
>
> (2)  If there is no (i)-th lexicographic successor, then the
>       corresponding variable binding produced in the Response-PDU has its
>       value field set to `endOfMibView', and its name field set to either
>       the last lexicographic successor, or if there are no lexicographic
>       successors, to the (N + r)-th variable binding's name in the
>       request.
>
> And the below response from the agent is in-line with RFC.
>
> Are you saying that endOfMibView is not handled OR the agent returning the response as below itself is incorrect ?
>
> Regards,
> Harsha
>
> -----Original Message-----
> From: SNMP4J [mailto:snmp4j-bounces at agentpp.org] On Behalf Of snmp4j-request at agentpp.org
> Sent: Saturday, July 19, 2014 3:30 PM
> To: snmp4j at agentpp.org
> Subject: SNMP4J Digest, Vol 90, Issue 11
>
> Send SNMP4J mailing list submissions to
> 	snmp4j at agentpp.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://oosnmp.net/mailman/listinfo/snmp4j
> or, via email, send a message with subject or body 'help' to
> 	snmp4j-request at agentpp.org
>
> You can reach the person managing the list at
> 	snmp4j-owner at agentpp.org
>
> When replying, please edit your Subject line so it is more specific than "Re: Contents of SNMP4J digest..."
>
>
> Today's Topics:
>
>     1. Re: TableUtils - STATUS_WRONG_ORDER = -2; endOfMibView
>        (Frank Fock)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 18 Jul 2014 20:39:42 +0200
> From: Frank Fock <fock at agentpp.com>
> To: snmp4j at agentpp.org
> Subject: Re: [SNMP4J] TableUtils - STATUS_WRONG_ORDER = -2;
> 	endOfMibView
> Message-ID: <53C969EE.4000206 at agentpp.com>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> Hi Harsha,
>
> You will have to write your own TableUtils class to change this behavior.
> But careful, there are many buggy agents like yours in the field.
>
> In your case, the bug is harmless (although it violates the standard).
>
> But other agents return lesser OIDs which can cause endless loops.
> Therefore, this check cannot be deactivated.
>
> Best regards,
> Frank
>
> Am 18.07.2014 09:45, schrieb Harsha H R:
>> Hi all,
>>
>>    
>>
>> I am trying to fetch a snmp table using TableUtils of snmp4j.
>>
>> The response to the get-bulk request issued by TableUtils is as follows:
>>
>>    
>>
>> -Simple Network Management Protocol
>>
>>                   version: v2c (1)
>>
>>                   community: public
>>
>>                   -data: get-response (2)
>>
>>                                   get-response
>>
>>                                                   request-id: 39446983
>>
>>                                                   error-status: noError
>> (0)
>>
>>                                                   error-index: 0
>>
>>                                                   -variable-bindings:
>> 14 items
>>
>>    
>> +1.3.6.1.4.1.7428.1.4.1.1.1.3.1.1:
>>
>>    
>> +1.3.6.1.4.1.7428.1.4.1.1.1.3.1.2:
>>
>>    
>> +1.3.6.1.4.1.7428.1.4.1.1.1.4.1.1:
>>
>>    
>> +1.3.6.1.4.1.7428.1.4.1.1.1.4.1.2:
>>
>>    
>> +1.3.6.1.4.1.7428.1.4.1.1.1.5.1.1:
>>
>>    
>> +1.3.6.1.4.1.7428.1.4.1.1.1.5.1.2:
>>
>>    
>> +1.3.6.1.4.1.7428.1.4.10.1.1.2.1:
>>
>>    
>> +1.3.6.1.4.1.7428.1.4.10.1.1.2.1: endOfMibView
>>
>>    
>> +1.3.6.1.4.1.7428.1.4.1.1.1.4.1.1:
>>
>>    
>> +1.3.6.1.4.1.7428.1.4.1.1.1.4.1.2:
>>
>>    
>> +1.3.6.1.4.1.7428.1.4.1.1.1.5.1.1:
>>
>>    
>> +1.3.6.1.4.1.7428.1.4.1.1.1.5.1.2:
>>
>>    
>> +1.3.6.1.4.1.7428.1.4.10.1.1.2.1:
>>
>>    
>> +1.3.6.1.4.1.7428.1.4.10.1.1.2.1: endOfMibView
>>
>>    
>>
>> The table event reports STATUS_WRONG_ORDER saying the response is not
>> in lexicographical order and is as below:
>>
>>    
>>
>>    
>> org.snmp4j.util.TableEvent[index=null,vbs=null,status=-2,exception=nul
>> l,repo
>> rt=null]
>>
>>    
>>
>> I guess this is because in the response to get-bulk request the oid
>> '1.3.6.1.4.1.7428.1.4.10.1.1.2.1' is repeated as end of MIB is reached.
>>
>> As a result I am not able to fetch the table contents.
>>
>>    
>>
>> Any idea on how to resolve this or a possible work around ?
>>
>>    
>>
>> Regards,
>>
>> Harsha
>>
>> _______________________________________________
>> SNMP4J mailing list
>> SNMP4J at agentpp.org
>> https://oosnmp.net/mailman/listinfo/snmp4j
> --
> ---
> AGENT++
> Maximilian-Kolbe-Str. 10
> 73257 Koengen, Germany
> https://agentpp.com
> Phone: +49 7024 8688230
> Fax:   +49 7024 8688231
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> SNMP4J mailing list
> SNMP4J at agentpp.org
> https://oosnmp.net/mailman/listinfo/snmp4j
>
>
> ------------------------------
>
> End of SNMP4J Digest, Vol 90, Issue 11
> **************************************
>
> _______________________________________________
> SNMP4J mailing list
> SNMP4J at agentpp.org
> https://oosnmp.net/mailman/listinfo/snmp4j

-- 
---
AGENT++
Maximilian-Kolbe-Str. 10
73257 Koengen, Germany
https://agentpp.com
Phone: +49 7024 8688230
Fax:   +49 7024 8688231




More information about the SNMP4J mailing list