Hi David,
One of my original problem was that when using snmpwalk command on say a
column (without any instance index) of one of the tables,
my subagent handler was getting called
once with getnext and next with get mode. I wasn't sure if that
was the expected sequence of calls.
I was not seeing any other subsequent calls to my handler after
those two calls.
This was caused by my code not responding correctly to getnext
due to not calling snmp_set_objoid() to update the oid name
with that of the next instance.
I changed the code and added the above net-snmp call and I have managed to
make progress! I think I'm beginning to understand this business of snmp ;-)
Thank you for taking the time to reply. It is been most helpful.
Bernadette
-----Original Message-----
From: [email protected] on behalf of Dave Shield
Sent: Fri 2/27/2009 3:24 AM
To: EYRE Bernadette
Cc: Mike Ayers; [email protected]; [email protected]
Subject: Re: help needed with root oid and getnext operation
2009/2/26 Bernadette Eyre <[email protected]>:
> My code registers organization root oid.
>
> (I substituted y and x in the oid to conceal some proprietary stuff)
Fair enough.
> I don't register the individual tables and scalars. The master agent
> knows of this root oid only. It knows to forward all the get/getnext
> calls under this oid to my subagent.
OK - I can see the logic in that.
If the one subagent is responsible for handling the whole of your
organisation's private OID space, then there's no need for the
master agent to know about the internal details.
A single AgentX registration would be both simpler and more efficient.
> I don't register tables or scalars because of two reasons:
> (1) we have several tables and scalars, the code would be huge
> if Iregister all the tables,
I'm not sure that particular argument holds up.
If the subagent is responsible for a large number of OIDs (regardless
of how they are structured), then *something* has to provide this
information. It's easier to maintain this code if this processing is
not handled by one big amorphous blob.
(As we discovered way way back at the start of this project.
One of my first submissions to Wes (Feb 1997 <gulp>) was dividing
the MIB processing into separate files, rather having it all in
snmp_vars.c).
In general, even if the subagent registers a single root with the
master agent, I would typically suggest that you should register
each table or group of scalars separately - even if this is only
visible within the subagent.
There's no fundamental requirement that the registrations received by
the subagent driving code *have* to be passed up to the master agent.
Howver:
> and (2) my sub-agent is not the keeper of the tables and scalars.
> the sub-agent uses propitiatory library to obtain the type and the value
> of the objects based on the oid passed to me by the master agent
> (net-snmp).
makes a lot more sense.
If your subagent is simply acting as a proxy for some other
mechanism which can handle all of the necessary processing,
then there is indeed no benefit of registering elements individually.
It sounds as if you're looking at a "SNMP filter" type module.
This feels broadly similar to the approach used in the master
side of AgentX processing.
(agent/mibgroup/agentx/master.c:agentx_master_handler()
and particularly agentx_got_response())
This code takes the varbinds from the incoming SNMP request,
converts them into an equivalent AgentX format (which is
pretty-near identical, I would agree!) and passes them off
to the appropriate subagent.
When the AgentX response comes back, the results are
extracted from that, and inserted back into the SNMP request:
from agentx_got_response():lines 370-ish ff
if (cache->reqinfo->mode == MODE_GET ||
cache->reqinfo->mode == MODE_GETNEXT ||
cache->reqinfo->mode == MODE_GETBULK) {
/*
* Replace varbinds for data request types, but not SETs.
*/
for (var = pdu->variables, request = requests; request && var;
request = request->next, var = var->next_variable) {
/*
* update the oid in the original request
*/
if (var->type != SNMP_ENDOFMIBVIEW) {
snmp_set_var_typed_value(request->requestvb, var->type,
var->val.string, var->val_len);
snmp_set_var_objid(request->requestvb, var->name,
var->name_length);
}
request->delegated = REQUEST_IS_NOT_DELEGATED;
}
:
>> > 3 - if I'm expected to return only the index (modified oid?)
>> > of the next valid instance...
You return the full OID of the next valid instance.
>> > .... do I modify the
>> > name field of the netsnmp_variable_list struct?
Yes - see above.
> In mygetnext() function, and when I'm called with getnext operation for
> an oid, say,
> var->name = {1,3,6,1,4,1,y,x,2}, if this oid has many instances what am
> I expected to return, the first object instance value
Yes.
Assuming y.x.2 is the root of a standard table, indexed using consecutive
integer values starting from 99, (and consecutive columns starting from 1)
then
mygetnext( y.x.2 )
should return the OID, type and value for the instance y.x.2.1.2.99
(assuming column 1 is the index object, which is not-accessible).
mygetnext( y.x.2.1.2.99 )
should return the OID, type and value for the instance y.x.2.1.2.100
mygetnext( y.x.2.1.2.123 ) (the last row in the table)
should return the OID, type and value for the instance y.x.2.1.3.99
(i.e. the first instance in the next column)
and so on
> using snmp_set_var_typed_value( var, snmpType,
> (uchar *)bufp, buflen);
> call?
Yes
> If so, do I modify the var->name and var->name_length to be of the
> actual instance
Yes.
See the AgentX code above.
> if the object has multiple instances how do I make the master agent call
> me again for the next instance?
It's not the master agent that will decide whether to ask for another varbind.
It's the original management app.
the master agent is simply acting as a pass-through filter.
In much the same way as your subagent is.
What's actually happening is that the management app is talking to the
proprietary mechanism. Neither the master agent nor the subagent actually
do any real work here - they just provide the framework for the two ends
to communicate.
> what is it that the master agent needs
> from the sub-agent to tell it to call the registered handler again for
> the next instance?
Nothing from the subagent.
It will receive a request from the management app,
and invoke the appropriate handler or subagent to process that request.
> My question regarding table handling is what net-snmp api's I have to
> use to build a reply for a table get or getnext calls?
As far as the SNMP protocol is concerned, there's nothing special
about tables at all. It works with a purely linear list of OIDs.
Interpreting these as scalar objects or tables is purely done by the
two ends. (The management app and the proprietary library).
If your sibagent is passing OIDs through to this library, then it doesn't
need to know what OIDs correspond to tables, or what indexing these
tables use (and more than the master agent handler does).
All of that can be dealt with by the library.
The code described above will work fine.
>> Similarly:
>>
>> > 2 - if I'm expected to return a value as a reply to GETNEXT
>> > call, why then my subagent is called again with GET mode?
>>
>> I can't answer that without some indication of what query is
>> being sent to the master agent. Is this a single GETNEXT
>> request, "snmpwalk" or what? What OID(s) are being requested,
>> and how do these relate to the OIDs of the subagent tables?
>> Exactly what OIDs does the subagent register anyway?
>>
> please see above comments.
But you _still_ haven't said anything about what SNMP requests
are being sent. Are you testing using "snmpgetnext" or "snmpwalk"
or something else? What OIDs are you sending in this query?
It is impossible to answer why the master/subagent communication
is behaving in this way, if we don't know what the master agent
is being asked to do.
This may be precisely the correct behaviour. I just don't know.
Dave
------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
