[SNMP4J] SNMP4J Digest, Vol 90, Issue 12
Frank Fock
fock at agentpp.com
Tue Jul 22 17:09:02 CEST 2014
Hi Harsha,
The response PDU does not contain any endOfMibView syntax and its
lexicographic order is OK. What is the issue with that PDU?
Best regards,
Frank
Am 22.07.2014 13:39, schrieb Harsha H R:
> Hi Frank,
>
> Below are the hex dumps:
>
> Get-Bulk Request
>
> 0000 00 14 6a 1c 83 05 00 25 64 a4 63 cc 08 00 45 00 ..j....% d.c...E.
> 0010 00 63 2d 1f 00 00 80 11 00 00 c0 a8 60 90 c0 a8 .c-..... ....`...
> 0020 23 f5 dd 92 00 a1 00 4f 06 37 30 45 02 01 01 04 #......O .70E....
> 0030 06 70 75 62 6c 69 63 a5 38 02 04 30 cb 6e 1f 02 .public. 8..0.n..
> 0040 01 00 02 01 0a 30 2a 30 13 06 0f 2b 06 01 04 01 .....0*0 ...+....
> 0050 ba 04 01 02 01 01 01 03 01 0a 05 00 30 13 06 0f ........ ....0...
> 0060 2b 06 01 04 01 ba 04 01 02 01 01 01 04 01 0a 05 +....... ........
> 0070 00 .
>
> response
>
> 0000 00 25 64 a4 63 cc 00 14 6a 1c 83 05 08 00 45 00 .%d.c... j.....E.
> 0010 01 f7 3d 29 00 00 fc 11 79 f6 c0 a8 23 f5 c0 a8 ..=).... y...#...
> 0020 60 90 00 a1 dd 92 01 e3 a0 cc 30 82 01 d7 02 01 `....... ..0.....
> 0030 01 04 06 70 75 62 6c 69 63 a2 82 01 c8 02 04 30 ...publi c......0
> 0040 cb 6e 1f 02 01 00 02 01 00 30 82 01 b8 30 14 06 .n...... .0...0..
> 0050 0f 2b 06 01 04 01 ba 04 01 02 01 01 01 03 01 0b .+...... ........
> 0060 42 01 00 30 14 06 0f 2b 06 01 04 01 ba 04 01 02 B..0...+ ........
> 0070 01 01 01 04 01 0b 02 01 24 30 14 06 0f 2b 06 01 ........ $0...+..
> 0080 04 01 ba 04 01 02 01 01 01 03 01 0c 42 01 03 30 ........ ....B..0
> 0090 14 06 0f 2b 06 01 04 01 ba 04 01 02 01 01 01 04 ...+.... ........
> 00a0 01 0c 02 01 24 30 14 06 0f 2b 06 01 04 01 ba 04 ....$0.. .+......
> 00b0 01 02 01 01 01 04 01 01 02 01 24 30 14 06 0f 2b ........ ..$0...+
> 00c0 06 01 04 01 ba 04 01 02 01 01 01 05 01 01 02 01 ........ ........
> 00d0 01 30 14 06 0f 2b 06 01 04 01 ba 04 01 02 01 01 .0...+.. ........
> 00e0 01 04 01 02 02 01 24 30 14 06 0f 2b 06 01 04 01 ......$0 ...+....
> 00f0 ba 04 01 02 01 01 01 05 01 02 02 01 01 30 14 06 ........ .....0..
> 0100 0f 2b 06 01 04 01 ba 04 01 02 01 01 01 04 01 03 .+...... ........
> 0110 02 01 24 30 14 06 0f 2b 06 01 04 01 ba 04 01 02 ..$0...+ ........
> 0120 01 01 01 05 01 03 02 01 01 30 14 06 0f 2b 06 01 ........ .0...+..
> 0130 04 01 ba 04 01 02 01 01 01 04 01 04 02 01 24 30 ........ ......$0
> 0140 14 06 0f 2b 06 01 04 01 ba 04 01 02 01 01 01 05 ...+.... ........
> 0150 01 04 02 01 01 30 14 06 0f 2b 06 01 04 01 ba 04 .....0.. .+......
> 0160 01 02 01 01 01 04 01 05 02 01 24 30 14 06 0f 2b ........ ..$0...+
> 0170 06 01 04 01 ba 04 01 02 01 01 01 05 01 05 02 01 ........ ........
> 0180 01 30 14 06 0f 2b 06 01 04 01 ba 04 01 02 01 01 .0...+.. ........
> 0190 01 04 01 06 02 01 24 30 14 06 0f 2b 06 01 04 01 ......$0 ...+....
> 01a0 ba 04 01 02 01 01 01 05 01 06 02 01 01 30 14 06 ........ .....0..
> 01b0 0f 2b 06 01 04 01 ba 04 01 02 01 01 01 04 01 07 .+...... ........
> 01c0 02 01 24 30 14 06 0f 2b 06 01 04 01 ba 04 01 02 ..$0...+ ........
> 01d0 01 01 01 05 01 07 02 01 01 30 14 06 0f 2b 06 01 ........ .0...+..
> 01e0 04 01 ba 04 01 02 01 01 01 04 01 08 02 01 24 30 ........ ......$0
> 01f0 14 06 0f 2b 06 01 04 01 ba 04 01 02 01 01 01 05 ...+.... ........
> 0200 01 08 02 01 01 .....
>
>
> Regards,
> Harsha
>
> -----Original Message-----
> From: SNMP4J [mailto:snmp4j-bounces at agentpp.org] On Behalf Of snmp4j-request at agentpp.org
> Sent: Tuesday, July 22, 2014 3:30 PM
> To: snmp4j at agentpp.org
> Subject: SNMP4J Digest, Vol 90, Issue 12
>
> 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: SNMP4J Digest, Vol 90, Issue 11 (Harsha H R)
> 2. Re: SNMP4J Digest, Vol 90, Issue 11 (Frank Fock)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 21 Jul 2014 16:34:16 +0530
> From: "Harsha H R" <harsha.hr at calsoftlabs.com>
> To: <snmp4j at agentpp.org>
> Cc: suresha at calsoftlabs.com
> Subject: Re: [SNMP4J] SNMP4J Digest, Vol 90, Issue 11
> Message-ID: <008501cfa4d3$85635cd0$902a1670$@calsoftlabs.com>
> Content-Type: text/plain; charset="UTF-8"
>
> 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
> **************************************
>
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 22 Jul 2014 00:54:44 +0200
> From: Frank Fock <fock at agentpp.com>
> To: snmp4j at agentpp.org
> Subject: Re: [SNMP4J] SNMP4J Digest, Vol 90, Issue 11
> Message-ID: <53CD9A34.5070304 at agentpp.com>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> 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=nu
>>> l
>>> 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
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> SNMP4J mailing list
> SNMP4J at agentpp.org
> https://oosnmp.net/mailman/listinfo/snmp4j
>
>
> ------------------------------
>
> End of SNMP4J Digest, Vol 90, Issue 12
> **************************************
>
> _______________________________________________
> 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