Hi,
I have done something similar recently (I provide some sample code below
- but note that ultimately everything is still done within the agent).
My Agent simply registers the root OID of the MIB it will handle and
some other function knows all about the data and the specific OIDs that
the Agent handles.
I just registered a generic handler for the root oid and then when it is
called, the handler make appropriate calls to handle the request. I
guess in your case you could then request the data (if any) from the
process/thread that holds the Data and OIDS.
Hope that helps.
Graeme
-------------
/* In your main/initialise function */
netsnmp_mib_handler* handler = netsnmp_create_handler(
"GenericOIDHandler", &genericOidHandler );
netsnmp_handler_registration* reg =
netsnmp_handler_registration_create( "GenericHandler",
handler,
root_oid,
OID_LENGTH(root_oid),
0 );
netsnmp_register_handler( reg );
/* Generic function which will be called for all OIDs below the root one
registered above */
int genericOidHandler( netsnmp_mib_handler *handler,
netsnmp_handler_registration *reginfo,
netsnmp_agent_request_info *reqinfo,
netsnmp_request_info *requests )
{
int ret = SNMP_ERR_NOERROR;
switch(reqinfo->mode)
{
case MODE_GET:
/* Call some other code to process the 'requests' argument */
ret = myData->getData( requests );
break;
case MODE_GETNEXT:
/* Call some other code to process the 'requests' argument */
ret = myData->getNextData( requests );
break;
default:
/* we should never get here in my code */
iRet = SNMP_ERR_GENERR;
break;
}
return ret;
}
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
> Behalf Of [EMAIL PROTECTED]
> Sent: 08 August 2007 06:51
> To: Mike Ayers
> Cc: [email protected]
> Subject: RE: Newbie question: writing a simple agent
>
> Hello Mike,
>
> thanks for replying to my question.
>
> I understand that a standard approach is to register the
> agent for a range of OISs and to let the agent to be OID
> aware while the other process should take care of the
> underlaying data.
>
> However, I was asked to write an agent that would NOT be
> OID-aware. All it would know it is responsible for a range of
> OIDs without knowing any details. It would forward complete
> OIDs to the other process that would take care about OID
> disassembly/translation, data manipulation etc.
>
> I am wondering if this is possible within the Net SNMP API, at all.
>
> If so, where should I start?
>
> Thanks.
>
> Milan
>
> On Tue, August 7, 2007 11:44 pm, Mike Ayers wrote:
> >
>
> >> From: [EMAIL PROTECTED]
> >> [mailto:[EMAIL PROTECTED] On Behalf Of
> >> [EMAIL PROTECTED]
> >>
> >
> >
> >> The agent itself will not be aware of individual OIDs and their
> >> meaning. This will be done by the other process that also
> holds the
> >> actual data.
> >
> > This is a bit of a design problem as stated. The (sub)agent is
> > responsible for managing its OID range, and therefore it is not
> > possible to have a subagent completely unaware of the OIDs.
> This does
> > not, however, mean that the subagent needs to be aware of the data
> > underlying the MIB.
> >
> > A common paradigm is to have the subagent register for the range of
> > values (table, MIB, whatever) that it will manage, and have the OP
> > (other
> > process) manage the data within the range. The agent does OID
> > assembly/disassembly (i.e. breaking OIDs into range part
> and specific
> > part), possibly reformat the specific part to make it more
> > understandable to the OP (thus only the subagent need be
> MIB aware).
> > The OP returns the values for the requested data, then the subagent
> > formats and assembles the response.
> >
> >
> > HTH,
> >
> >
> > Mike
> >
> >
> >
> ----------------------------------------------------------------------
> > --- This SF.net email is sponsored by: Splunk Inc.
> > Still grepping through log files to find problems? Stop.
> > Now Search log events and configuration files using AJAX
> and a browser.
> > Download your FREE copy of Splunk now >> http://get.splunk.com/
> > _______________________________________________
> > 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
> >
> >
> >
>
>
>
> --------------------------------------------------------------
> -----------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and
> a browser.
> Download your FREE copy of Splunk now >>
> http://get.splunk.com/ _______________________________________________
> 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
>
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
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
