Hi Milan, No worries about the questions.
For my subagent (binary/executable) I doctored an existing 'main' that I had from when I'd created a subagent with mib2c - its just like your example below: - init_agent - etc etc - register your handler here - loop (agent_check_and_process) - etc etc Cheers Graeme > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: 08 August 2007 14:47 > To: Graeme Wilson > Cc: net-snmp-users@lists.sourceforge.net > Subject: RE: Newbie question: writing a simple agent > > Hello Graeme, > > I went through your code and it seems it is exactly what I need. > > I am just confused about one thing: how does it plug into snmpd? > > I understand that I need to do in agent main() registration > (and un-registration at agent finish) but what do I actually > generate? > > Should I create a binary like in MFD example and loop using > agent_check_and_process() or snmp_select_info() or should I > create some kind of .so that does mere regsitration and finishes? > > In the former case the scenario is > - init_agent > - init_snmp > - init_master_agent(); > - register handler > - loop > - un-register handler > - snmp_shutdown > > or am I missing something? > > Sorry for asking you newbie trivial questions :-) > > Thanks. > > Milan > > > > > > On Wed, August 8, 2007 11:11 am, Graeme Wilson wrote: > > > > > 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: net-snmp-users@lists.sourceforge.net > >> 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 > >>> Net-snmp-users@lists.sourceforge.net > >>> 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 > >> Net-snmp-users@lists.sourceforge.net > >> 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 > > Net-snmp-users@lists.sourceforge.net > > 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 Net-snmp-users@lists.sourceforge.net Please see the following page to unsubscribe or change other options: https://lists.sourceforge.net/lists/listinfo/net-snmp-users
