Re: Properly handling skipped columns

Dave Shield <[email protected]>
Newsgroups gmane.network.net-snmp.user
Message-ID <[email protected]>
On 14 July 2010 21:16,  <[email protected]> wrote:
>  I implemented the MIB's for this agent with the table array helper.
> My issue is that I need to decide at runtime if a given row is to skip over a column or not.

I'm not personally familiar with that particular helper,
so I'll leave others (?Robert) to answer the details.

    [Though I do notice a comment in the table_array.c file:

           /* xxx-rks: add suport for sparse tables */

    ]

However, in response to your more general questions:


> So, as an agent, how do I implement a response that tells
> snmpwalk to keep going onto the next OID?

It's up to the agent to determine the next valid OID, and return that value.


> I am thinking it has to be implemented along the lines of:
>     Request 1.1.1, Receive 1.1.1,
>     Request 1.1.2, Receive SKIP,
>     Request 1.1.3, Request 1.1.3.

No - that's not how snmpwalk works.
Instead, it's more like:

       RequestNext <start>    Receive 1.1.1
       RequestNext 1.1.1        Receive 1.1.3

Skipping any missing entries is the responsibility of the agent,
not the client application.



> What is the preferred way to handle a skipped column?

With the table_array helper?   No idea!
With most of the others that I tend to use (e.g. table_tdata),
then simply not setting a value should be sufficient for the
agent to move on to the next OID automatically.

Dave

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.