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:[email protected]] On Behalf Of
[email protected]
Sent: Saturday, July 19, 2014 3:30 PM
To: [email protected]
Subject: SNMP4J Digest, Vol 90, Issue 11
Send SNMP4J mailing list submissions to
[email protected]
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
[email protected]
You can reach the person managing the list at
[email protected]
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 <[email protected]>
To: [email protected]
Subject: Re: [SNMP4J] TableUtils - STATUS_WRONG_ORDER = -2;
endOfMibView
Message-ID: <[email protected]>
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
[email protected]
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
[email protected]
https://oosnmp.net/mailman/listinfo/snmp4j
------------------------------
End of SNMP4J Digest, Vol 90, Issue 11
**************************************
_______________________________________________
SNMP4J mailing list
[email protected]
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
_______________________________________________
SNMP4J mailing list
[email protected]
https://oosnmp.net/mailman/listinfo/snmp4j
