[SNMP4J] SNMP4J Digest, Vol 90, Issue 12
Harsha H R
harsha.hr at calsoftlabs.com
Tue Jul 22 13:39:29 CEST 2014
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
**************************************
More information about the SNMP4J
mailing list