Thank you for your answer Dave. However, your suggestion of using the varbind
list only works for single GET operations of the table entries. Using snmptable
command to perform GETNEXT or GETBULK causes the values to be incorrect.
As a reminder, my table initialization code looks like this.
table_reg = netsnmp_create_handler_registration("tableDemoMyTableTable",
tableDemoTable_handler,
tableDemoTable_oid,
OID_LENGTH(tableDemoTable_oid),
HANDLER_CAN_RWRITE);
table_set = netsnmp_create_table_data_set("tableDemoMyTableTable");
netsnmp_table_set_add_indexes(table_set, ASN_UNSIGNED, 0);
netsnmp_table_set_multi_add_default_row(table_set,
1, ASN_UNSIGNED, 0, NULL, 0,
3, ASN_INTEGER, 1, NULL, 0,
5, ASN_INTEGER, 0, NULL, 0,
0);
netsnmp_register_table_data_set(table_reg, table_set, NULL);
for (index = 0; index <= MAXINDEX; index++)
{
if ((5 <= index) && (index <= MAXINDEX))
{
values[index] = 100 + (int) index;
row = netsnmp_create_table_data_row();
netsnmp_table_row_add_index(row, ASN_UNSIGNED, &index,
sizeof(index));
netsnmp_set_row_column(row, 1, ASN_UNSIGNED, &index,
sizeof(index));
netsnmp_mark_row_column_writable(row, 1, 0);
netsnmp_set_row_column(row, 3, ASN_INTEGER, &(values[index]),
sizeof(values[index]));
netsnmp_mark_row_column_writable(row, 3, 1);
netsnmp_set_row_column(row, 5, ASN_INTEGER, &version,
sizeof(version));
netsnmp_mark_row_column_writable(row, 5, 1);
netsnmp_table_dataset_add_row(table_set, row);
value_tableDemoNumber++;
}
}
For example, using the snmptable command, I read the values of a table that has
3 columns and 4 rows. The first column is the integer index. The resulting
output is:
index tableDemoMyTableIndex tableDemoMyTableValue tableDemoMyTableVersion
6 5 2002757 1
7 6 2002757 1
8 7 2002757 1
My MIB is structured as follows:
-- 1.3.6.1.4.1.8072.2007.1.1.1.2.2.1
tableDemoMyTableEntry OBJECT-TYPE
SYNTAX tableDemoMyTableEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
""
INDEX { tableDemoMyTableIndex }
::= { tableDemoMyTableTable 1 }
tableDemoMyTableEntry ::=
SEQUENCE {
tableDemoMyTableIndex
Unsigned32,
tableDemoMyTableValue
Integer32,
tableDemoMyTableVersion
Integer32
}
-- 1.3.6.1.4.1.8072.2007.1.1.1.2.2.1.1
tableDemoMyTableIndex OBJECT-TYPE
...
::= { tableDemoMyTableEntry 1 }
-- 1.3.6.1.4.1.8072.2007.1.1.1.2.2.1.3
tableDemoMyTableValue OBJECT-TYPE
...
::= { tableDemoMyTableEntry 3 }
-- 1.3.6.1.4.1.8072.2007.1.1.1.2.2.1.5
tableDemoMyTableVersion OBJECT-TYPE
...
::= { tableDemoMyTableEntry 5 }
Notice that use of table_info->indexes->next_variable causes the handler code
in the MODE_GET section retrieve the data with an index off-by-one error, and
report the first row no such instance. From some printf statements, it appears
that the MODE_GET handler invocations are in this order:
index=-1 colnum=1
index=5 colnum=1
index=6 colnum=1
index=7 colnum=1
index=8 colnum=2
index=-1 colnum=3
index=5 colnum=3
index=6 colnum=3
index=7 colnum=3
index=8 colnum=4
index=-1 colnum=5
index=5 colnum=5
index=6 colnum=5
index=7 colnum=5
An example of what I am doing:
switch (reqinfo->mode) {
case MODE_GET:
for (request=requests; request; request=request->next) {
table_info = netsnmp_extract_table_info(request);
index = tableDemoQueryIndex(table_info);
table_entry = myLookupMethod(index);
switch (table_info->colnum) {
case 1:
if (!((5 <= index) && (index <= MAXINDEX)))
{
netsnmp_set_request_error(reqinfo, request,
SNMP_NOSUCHINSTANCE);
continue;
}
snmp_set_var_typed_integer(request->requestvb, ASN_UNSIGNED,
table_entry->index);
break;
... ... ...
Regards,
Timothy
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of Dave Shield
Sent: Friday, November 11, 2011 8:42 AM
To: STOTTS Timothy
Cc: [email protected]
Subject: Re: how to determine table query index in snmp subagent table handler?
On 10 November 2011 23:03, Dave Shield <[email protected]> wrote:
>> Example handler code:
>
>> int index;
>
>> for (request=requests; request; request=request->next) {
>> index = request->index;
>
> Isn't this what you are looking for?
Sorry - you're right of course.
This is the index of the varbind within the incoming request
(1 for the first or only varbind, 2 for the second, etc).
[ I really shouldn't try to respond to queries on the
list, just before going to bed!]
The list of index value(s) as parsed from the incoming OID
can be retrieved using:
for (request=requests; request; request=request->next) {
netsnmp_table_request_info *table_info =
netsnmp_extract_table_info(request);
and the individual index values are accessible from table_info->indexes,
table_info->indexes->next_variable, etc
These are normal VarBind structures, so ignore the OID fields, and just
look at the value field.
For a simple table (with a single integer index), it's probably easier
to extract thie index directly from the OID itself, but for more complex
tables (strings, OIDs or multiple indexes), it makes sense to use this
varbind list.
Dave
________________________________
CONFIDENTIALITY : This e-mail and any attachments are confidential and may be
privileged. If you are not a named recipient, please notify the sender
immediately and do not disclose the contents to another person, use it for any
purpose or store or copy the information in any medium.
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
Net-snmp-users mailing list
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
