It really depends on being able to see your agent's data from a program which 
is not itself SNMP and using sockets which are not SNMP's sockets

I'm assuming you are talking about two different machines, one containing an 
agent and the other a manager

You want to interrogate data which is in the SNMP agent's space without 
actually being that agent. If you are talking about an embedded system with a 
flat global address space, this is easy. Otherwise you may find it best to 
include your piece of enquiry code in your agent

It doesn't sound important to me at all, but this is how you do it

you don't use SNMP's sockets. You use one of the other 60000 available socket 
addresses on the target system

It will be easiest if your new piece of code is a thread of the agent

#include <sys/socket.h>
#include <netinet/in.h>
#include <errno.h>

static struct sockaddr_in here  = { AF_INET, 
HTONS(A_NICE_PORT_NUMBER_MAYBE_44004) } ;
static struct sockaddr_in there = { AF_INET } ;
static int sixteen = 16;

void listener()
{
   int                   s = socket(AF_INET, SOCK_DGRAM);
   int                   x = bind(s, (struct sockaddr *) &here, 16);

   char          data[DATA];

   if (s < 0) printf("yon's mingin\n");
   else
   {
      if (x < 0) printf("yon's awfu\n");
      else
      {
         for (;;)
         {
            x = recvfrom(s, data, DATA, 0, (struct sockaddr *) &there, 
&sixteen);
            if (x < 0) break

           
/************************************************************************

                find your data and format your response

          
************************************************************************/

            x = send(s, data, HOWEVER_LONG_YOUR_RESPONSE_IS, 0, (struct 
sockaddr *) &there, 16);
         }

         printf("listener stopped %d\n", errno);
      }
   }
}

and you need something in your GUI program to call this listener. Decide for 
yourself if it should block on response. I don't advise it. But I don't advise 
you to make this feature of your application so important in the first place

#include <sys/socket.h>
#include <netinet/in.h>
#include <errno.h>

int requestor(char *data)
{
   static struct sockaddr_in there  = { AF_INET, 
HTONS(A_NICE_PORT_NUMBER_MAYBE_44004),
                                                          {  
REMOTE_NETWORK_ADDRESS } } ; 
   static struct sockaddr_in  here = { AF_INET } ;
   static int sixteen = 16;
 
   static int s = -1;

   int                           x;

  
   if (s < 0)
   {
      s = socket(AF_INET, SOCK_DGRAM);

      if (s < 0) return -1;

      x = bind(s, (struct sockaddr *) &here, 16);
      if (x < 0)
      {
         s = -1;
         return -2
      }
   }

   x = sendto(s, data, sizeof(enquiry), 0, (struct sockaddr *) &there, 16);
   of (x < 0) return -3;
   x = recvfrom(s, data, MAXIMUM, 0, (struct sockaddr *), &there, &sixteen);
   if (x < 0) return -4;
   return x;
}




Am 02.05.2013 um 08:39 schrieb Gustav Evertsson:

> 
> Can you describe the socket method a bit more? I have tested to implement it 
> with these calls, but that will increase the counters:
> 
> snmp_sess_init( &session );
> session.peername = "127.0.0.1";
> ....
> SOCK_STARTUP;
> ss = snmp_open(&session); 
> snmp_synch_response(ss, pdu, &response);
> snmp_close(ss);
> SOCK_CLEANUP;
> 
> /Gustav
> 
> On Tue, 30 Apr 2013 15:44:56 +0200 (CEST)
>  "Tim Cox" <timmiles...@gmx.ch> wrote:
> >        If this is really so important     access the MIB variables
> > from a socket program     or decrement the send and receive counts by
> > 1 between acquiring and displaying  (you need a running count of
> > course)        Gesendet: Dienstag, 30. April 2013 um 15:35 Uhr Von:
> > "Gustav Evertsson" <m...@guzzzt.com> An: "Tim Cox" <timmiles...@gmx.ch>
> > Cc: net-snmp-coders@lists.sourceforge.net Betreff: Re: Access the
> > SNMP Counters without increasing them   Yes, the problem is that they
> > are increased when read from the GUI. They should only be increased
> > when read from SNMP. When the user opens the GUI it is not visible
> > that the counters comes from the SNMP interface and it therefore
> > looks strange to the user. I could inform them that the request goes
> > over SNMP and is therefore included but I would rather access the
> > counters in a way that does not affect them.  /Gustav   On Tue, 30
> > Apr 2013 13:10:11 +0200 (CEST)  "Tim Cox" <timmiles...@gmx.ch> wrote:
> > >        It depends how your MIB is implemented     You may be able
> > to > see these counters from a simple socket application, maybe not >
> >     But how can it be so important? It should be reassuring that your
> > > enquiry traffic is also shown. Do you want to avoid incrementing
> > the > interface counters as well?              Gesendet: Dienstag,
> > 30. > April 2013 um 09:47 Uhr Von: "Gustav Evertsson" <m...@guzzzt.com>
> > An: > net-snmp-coders@lists.sourceforge.net Betreff: Access the SNMP
> > > Counters without increasing them   I am developing an application >
> > that have both an SNMP interface and a GUI. I would like to access >
> > the SNMP counters like snmpInPkts, snmpOutPkts etc to show in the >
> > GUI. I have tested to send SNMP request to localhost and it works but
> > > it also increases the counters and is therefore not so nice. >
> > Reloading the GUI will show increased counters even if there has been
> > > no outside SNMP requests. Is there a way to access these counters
> > by > some API call instead?  I9m interested in the counters under >
> > 1.3.6.1.2.1.11 and 1.3.6.1.6.3.15.1.1 and 1.3.6.1.6.3.11.2.1.
> >             
> 

------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
_______________________________________________
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Reply via email to