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
------------------------------------------------------------------------------
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
