Re: Wireshirk: net-snmp 5.4.3: table snmpwalk without using GETNEXT?
Dave Shield
>> I'm using wireshark 1.2.11 to monitor SNMP traffic, I observed when I
>> snmpwalk through MyTable, there are a lot of GETNEXT request sent out, but
>> in my handler, branch GETNEXT doesn't get executed....
> Ok, I have found in netsnmp_table_iterator_helper_handler(), it changes all
> GETNEXT requests to GET. ( Line 778 in table_iterator.c for netsnmp-5.4.3).
This approach is common to a number of the table helpers.
If the helper framework knows (or can find out) the list of valid rows,
then it can automatically determine which row is needed to answer a
given GETNEXT request. The request can then be converted into an
equivalent GET request, which is much easier for the MIB-specific handler
to process.
Dave
------------------------------------------------------------------------------
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
_______________________________________________
Net-snmp-coders mailing list
Net-snm...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
Dave Shield
> As to my understanding (and your hints),
> netsnmp_table_iterator_helper_handler goes through each row first; Then for
> each row, it stores each column data(data_context) in TI_REQUEST_CACHE;
Close - but not quite.
The iterator goes through each row of the table.
For each row, it checks each varbind from the incoming request
to see whether the row is the one required for that particular varbind.
If so, then it remembers the data context for that row
> After it finishes loop for all the rows, it read column data(data_context)
> back from TI_REQUEST_CACHE and put them in each request's (== each column's)
> TABLE_ITERATOR_NAME datalist, and then return.
After the iterator has finished working through all of the rows of the table,
it associates the appropriate row for each varbind with the request strucrure
for that varbind, and finally calls the MIB-specific handler.
Note that the list of 'request' structures is based on the list of varbinds
from the incoming PDU, *not* the list of columns in the table.
Dave Shield
> Right, I took it for granted that the varbinds for "each requests" is for
> the columns of "each row". There may be holes in table so this may not be
> the case. Nevertheless, is this assertion true for the "full-filled" table
> (a varbind in one requests list == a request ==a column in a row)?
Not necessarily.
The list of varbinds in the incoming request depends purely
on what the original client application asked for.
It is perfectly possible for the client to request two column values
from one row of a table, another column value from a different
row of the same table, a value from a completely different table
and a scalar instance - all in the same request.
I can't think *why* the client should send such a strange
assortment of values - but that doesn't matter. It's not for
the agent to restrict what it's prepared to report. It should
simply provide the values requested.
So in the case (for example) of
snmpget .... myName.1 myNumber.3 myEmail.1
the iterator helper would work through the list of rows in myTable,
and associate the data structure for row 1 with the first and
third varbinds, and associate the data structure for row 3
with the second varbind.
The MIB handler can then retrieve this associated row data
structure from each 'request' link in the chain, and be confident
that this contains the relevant data for that varbind.
It doesn't matter how many other column objects there are,
or whether there are holes in the table. The 'request' list
is purely concerned with the varbinds from the incoming request.
Dave Shield
> I'm asking this because I am using "snmpwalk" to send the requests,
> so, is it true for the most nature case, my explanation is right?
If you are using "snmpwalk", then this sends a series of GETNEXT
requests, each containing a single varbind.
So in this case, the "requests" list contains just one entry.
Remember, the basic iterator model is that the 'get_first/get-next'
loop is run for *every* incoming SNMP PDU. It starts at the
beginning of the table and loops through all of the rows until
it finds the appropriate row for this request.
The get_first/get_next loop does not match the step-by-step nature
of "snmpwalk". It's concerned with the processing of a single PDU.
So walking one column of the table (N rows) will result in N full passes
of the get_first/get_next loop.
[This may already be clear to you, but it's a fairly common misunderstanding]
> Otherwise, the requests is one column after the other.
Strictly speaking, for "snmpwalk", the requests will be for the same column,
but one row after another. Only when you reach the last row of the table,
then you'll move on to the next column (and back to the first row again).
> tried using "snmpget" to retrieve the data in your way, and mbrowse to
> retrieve only one MO (column) in one row from a table but it failed
That description is a little bit vague.
What was the exact "snmpget" command that you tried?
(And for comparison, what's the full output from snmpwalk?)
Dave Shield
>> What was the exact "snmpget" command that you tried?
>> (And for comparison, what's the full output from snmpwalk?)
>>
>
>
> 1) snmpget:
> 1a) command line: snmpget ... Table.1.Column1.index
Please can you post the *exact* command that you are using.
Preferably cut-and-paste from the command line.
Not a generalised version of it - the *exact* command please.
> 2) snmpwalk:
>
> 2a) CLI: snmpwalk ... Table.1.Column1
>
> output: OK. Read all vaule for one column; (but read whole table failed
> with error same as that in 1a))
Again, that's really too vague to be useful.
Please post the exact command(s) and full output.
> I just can't conceive an example let me go through one row's columns first,
> then move to next row.... Is this to say Snmpv1 is not capable to handle
> table efficiently
It's nothing to do with SNMPv1 vs SNMPv2 - this is a consequence of
the basic behaviour of the GETNEXT command, combined with the
OID ordering rules of SMI.
An "snmpwalk" will *always* traverse tables column by column,
rather than row-by-row. Regardless of version. That's how SNMP works.
> (maybe snmpget ... table.column1, table.column2,..., table.columnX can do it)?
"snmpget" is no use here - GET requires you to know the index(es) of
each row in advance. You'd need to use "snmpgetnext" instead - that
could indeed take all of the column objects as parameters, and walk
the table in parallel.
Or else use the "snmptable" command, which does exactly this already.
> Is this to say Snmpv1 is not capable to handle table efficiently
SNMPv1 can handle this perfectly sensibly - you just need to
use the right tool. Have a look at the workings of "snmptable"
rather than "snmpwalk".
> I'm implementing my project based on
> net-snmp table, and I need to return one row after the other in order.
No - you don't. You need to return the results appropriate
for whatever was in the incoming request.
If the incoming requests are asking for each row in turn,
then that's what the agent should report.
If the incoming requests are asking for random elements,
then *that* is what the agent should report.
As long as the agent is working correctly, then you'll get
the right results.
But it's up to the client tools to request the appropriate OIDs,
and keep track of what to ask for next. SNMP is essentially
a "stateless" protocol (much the same as HTTP), and the
agent doesn't need to keep track of who has asked it for what.
Dave Shield
> I'm going to try snmptable command,
> better to have snmptable command in mbrowse...
You'll have to talk to the mbrowse developers about that.
It's nothing to do with the Net-SNMP project.
(other than apparently being built on out toolkits)
Dave
------------------------------------------------------------------------------
Forrester Wave Report - Recovery time is now measured in hours and minutes
not days. Key insights are discussed in the 2010 Forrester Wave Report as
part of an in-depth evaluation of disaster recovery service providers.
Forrester found the best-in-class provider in terms of services and vision.
Read this report now! http://p.sf.net/sfu/ibm-webcastpromo
Dave Shield
> Here are exact output:
>
> 1a) snmpget
>
> # snmpget -v 2c -c public localhost .1.3.6.1.2.1.192.1.2
> .1.3.6.1.2.1.192.1.2 = No Such Object available on this agent at this OID
Yes - that is correct.
For "snmpget", you have to provide the OID of an instance of a column
object within the table. Not the OID of the table itself.
> 3) snmptable
>
> # snmptable -v 2c -c public localhost .1.3.6.1.2.1.192.1.2
> Was that a table? .1.3.6.1.2.1.192.1.2
Do you have the SYSLOG-MSG-MIB loaded?
While most of the client tools can work with numeric OIDs,
snmptable *must* have the MIB file available, so that it
knows which column objects to request.
You still haven't provided the output from "snmpwalk"
that I asked for.
Dave Shield
>> You still haven't provided the output from "snmpwalk" that I asked for.
>
No - please post the *WHOLE* of the output.
(Probably as an attachment would be best).
Or at least make it available on a website somewhere,
and post a link to it.
I cannot hope to help you track down what is going wrong
if I'm constantly working with incomplete information!
> I reset Index
> counter to 1 in loop_free_at_end, and the snmpwalk just returns the latest
> syslog record in snmpwalk command (the "stCnt: 1" is the debug record).
What happens if you do *not* reset the index counter here?
The purpose of the 'free_loop_context_at_end" hook
(which is what I presume you are referring to here) is to release
any resources that you have allocated during the get_first/next cycle.
It's probably not sensible to try and do anything else.
Perhaps you should post the full code of your MIB module.
so that we can see exactly what you are doing, and what might
be going wrong.
Dave Shield
> Dave, attached is my code.
And the header files?
> The rationale behind the code is to set index value at every beginning of
> column loop. When loop goes back to the beginning of next column, the index
> is reset to 1 and count again.
The iterator framework should already take care of wrapping
round to the next column.
Please try *without* this statement.
Dave Shield
Not unless you send the header files I asked for.
In order to help you solve this problem, I need to reproduce it
first - which means I need a version of the agent that includes
this module. Without the missing header files, I cannot do this.
I'm happy to try and help you, but it is incredibly frustrating
(and a waste of time) to have to ask for stuff (be it output
or files) two or three times, before it finally appears!
Grrrrr....
Dave Shield
> On 12 April 2011 15:38, Zimmer Hu <zih...@gmail.com> wrote:
>> Could you tell me which way is the right way to make such a change?
>
> Not unless you send the header files I asked for.
Oops!
Sorry - I've just spotted the later message that included them.
OK - I'll try and reproduce the problem, and see what I can find out.
It'll probably be sometime tomorrow.