[prev in list] [next in list] [prev in thread] [next in thread]
List: net-snmp-coders
Subject: mib2c.row.conf and agent/helpers/table_row.c
From: Paul Stath <stath.paul () gmail ! com>
Date: 2013-06-05 20:32:04
Message-ID: CALBYoJfSivqbooAc+w0U8o+M2WXCoKB4jxCV_3EWo5DHFr-TrQ () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
I'm looking to implement a table that will be split into individual rows
between different sub-agents.
The table will not allow for row creation.
Each sub-agent will implement one or more rows in the table.
It looks like the agent/helpers/table_row.c file is designed to be the
table helper for such a table.
In looking for example MIB implementations that used
netsnmp_table_row_register(), I found the mib2c.row.conf template.
Note that I did NOT find any MIB implementations using
netsnmp_table_row_register().
When attempting to use the module generated by this template, I'm having
problems with GETNEXT requests.
If I attempt to 'snmpwalk' or 'snmpgetnext' using the table OID as the
starting point, the _table_row_default_handler() will be called,
since it is registered with rootoid == table OID. reqinfo->mode ==
GETNEXT. Since reqinfo->mode is not checked by the
default table handler, it will return NOSUCHINSTANCE.
Since NOSUCHINSTANCE/NOSUCHOBJECT result codes should only be returned for
GET requests, I modified the
code to handle GETNEXT and GETBULK requests by simply returning
ENDOFMIBVIEW, else invoke the existing logic
for GET requests only.
It appears to me that the purpose of the table_row_default_handler() is to
handle a GET request on a table column with a
non-existent instance OID. Is that correct?
Once the _table_row_default_handler() began returning ENDOFMIBVIEW, the
_table_row_handler() method is now being
called for the registered row with the lowest index.
Currently, the _table_row_handler() simply stashes a pointer to the row
data in each request data linked list,
then calls the next handler in the processing chain.
As generated by mib2c.row.conf, this is the generated handler method for
the MIB table.
The generated code does not do any GETNEXT processing. I didn't find this
odd, since code generated for
use with table_container does not process GETNEXT message either.
I would expect the _table_row_handler to process GETNEXT requests similar
to how the _table_container_handler()
converts GETNEXT requests into GET requests of the next available row. In
this case, since _table_row_handler
only can process the current row, I would expect it to either convert the
GETNEXT request into a GET for the
next accessible column in the row, or return ENDOFMIBVIEW if past the last
column in the row.
Am I missing something, or does the agent/helpers/table_row.c module need
some love to handle GETNEXT request
properly?
Should the GETNEXT processing for the table_row helper be in the
_table_row_handler() method, or it is better implemented
elsewhere?
Please advise.
Thank you.
--
Paul Stath
Senior Software Engineer
Axxcelera Broadband Wireless
[Attachment #5 (text/html)]
<div dir="ltr">I'm looking to implement a table that will be split into \
individual rows between different sub-agents.<div><br></div><div style>The table will \
not allow for row creation.</div><div style>Each sub-agent will implement one or more \
rows in the table.</div> <div style><br></div><div style>It looks like the \
agent/helpers/table_row.c file is designed to be the table helper for such a \
table.</div><div style><br></div><div style>In looking for example MIB \
implementations that used netsnmp_table_row_register(), I found the mib2c.row.conf \
template.</div> <div style>Note that I did NOT find any MIB implementations using \
netsnmp_table_row_register().</div><div style><br></div><div style>When attempting to \
use the module generated by this template, I'm having problems with GETNEXT \
requests.</div> <div style><br></div><div style>If I attempt to 'snmpwalk' or \
'snmpgetnext' using the table OID as the starting point, the \
_table_row_default_handler() will be called,<br></div><div style>since it is \
registered with rootoid == table OID. reqinfo->mode == GETNEXT. Since \
reqinfo->mode is not checked by the</div> <div style>default table handler, it \
will return NOSUCHINSTANCE.</div><div style><br></div><div style>Since \
NOSUCHINSTANCE/NOSUCHOBJECT result codes should only be returned for GET requests, I \
modified the</div><div style> code to handle GETNEXT and GETBULK requests by simply \
returning ENDOFMIBVIEW, else invoke the existing logic<br></div><div style>for GET \
requests only.</div><div style><br></div><div style>It appears to me that the purpose \
of the table_row_default_handler() is to handle a GET request on a table column with \
a</div> <div style>non-existent instance OID. Is that correct?</div><div \
style><br></div><div style>Once the _table_row_default_handler() began returning \
ENDOFMIBVIEW, the _table_row_handler() method is now being</div><div style> called \
for the registered row with the lowest index.</div><div style><br></div><div \
style>Currently, the _table_row_handler() simply stashes a pointer to the row data in \
each request data linked list,</div><div style>then calls the next handler in the \
processing chain.</div> <div style><br></div><div style>As generated by \
mib2c.row.conf, this is the generated handler method for the MIB table.</div><div \
style>The generated code does not do any GETNEXT processing. I didn't find this \
odd, since code generated for</div> <div style>use with table_container does not \
process GETNEXT message either.</div><div style><br></div><div style>I would expect \
the _table_row_handler to process GETNEXT requests similar to how the \
_table_container_handler()</div> <div style>converts GETNEXT requests into GET \
requests of the next available row. In this case, since _table_row_handler</div><div \
style>only can process the current row, I would expect it to either convert the \
GETNEXT request into a GET for the</div> <div style>next accessible column in the \
row, or return ENDOFMIBVIEW if past the last column in the row.</div><div \
style><br></div><div style>Am I missing something, or does the \
agent/helpers/table_row.c module need some love to handle GETNEXT request</div> <div \
style>properly?</div><div style><br></div><div style>Should the GETNEXT processing \
for the table_row helper be in the _table_row_handler() method, or it is better \
implemented</div><div style>elsewhere?</div><div style> <br></div><div style>Please \
advise.</div><div style><br></div><div style>Thank you.</div><div \
style><br></div><div style>--</div><div style>Paul Stath<br></div><div style>Senior \
Software Engineer</div><div style>Axxcelera Broadband Wireless</div> <div \
style><br></div></div>
------------------------------------------------------------------------------
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j
_______________________________________________
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic