Re: about net-snmp 64bits data

"Alexander King" <[email protected]>
Newsgroups gmane.network.net-snmp.user
Message-ID <[email protected]>
Dave,about 64bits data run on net-snmp I found something below,it is in the right direction?
 

00080 #define IS_CONSTRUCTOR(byte)    ((byte) & ASN_CONSTRUCTOR)
00081 #define IS_EXTENSION_ID(byte)   (((byte) & ASN_EXTENSION_ID) == ASN_EXTENSION_ID)
00082 
00083     struct counter64 {
00084         u_long          high;
00085         u_long          low;
00086     };
00087 
00088 #ifdef NETSNMP_WITH_OPAQUE_SPECIAL_TYPES
00089     typedef struct counter64 integer64;
00090     typedef struct counter64 unsigned64;

 
/*---------------------------------------------------------------------
 * IP-MIB::ipSystemStatsEntry.ipSystemStatsHCInReceives
 * ipSystemStatsHCInReceives is subid 4 of ipSystemStatsEntry.
 * Its status is Current, and its access level is ReadOnly.
 * OID: .1.3.6.1.2.1.4.31.1.1.4
 * Description:
The total number of input IP datagrams received, including
            those received in error.  This object counts the same
            datagrams as ipSystemStatsInReceives but allows for larger
 
 
 

            values.
 

            Discontinuities in the value of this counter can occur at
            re-initialization of the management system, and at other
            times as indicated by the value of
            ipSystemStatsDiscontinuityTime.
 *
 * Attributes:
 *   accessible 1     isscalar 0     enums  0      hasdefval 0
 *   readable   1     iscolumn 1     ranges 0      hashint   0
 *   settable   0
 *
 *
 * Its syntax is COUNTER64 (based on perltype COUNTER64)
 * The net-snmp type is ASN_COUNTER64. The C type decl is U64 (U64)
 */
/**
 * Extract the current value of the ipSystemStatsHCInReceives data.
 *
 * Set a value using the data context for the row.
 *
 * @param rowreq_ctx
 *        Pointer to the row request context.
 * @param ipSystemStatsHCInReceives_val_ptr
 *        Pointer to storage for a U64 variable
 *
 * @retval MFD_SUCCESS         : success
 * @retval MFD_SKIP            : skip this node (no value for now)
 * @retval MFD_ERROR           : Any other error
 */
int
ipSystemStatsHCInReceives_get(ipSystemStatsTable_rowreq_ctx * rowreq_ctx,
                              U64 * ipSystemStatsHCInReceives_val_ptr)
{
   /** we should have a non-NULL pointer */
    netsnmp_assert(NULL != ipSystemStatsHCInReceives_val_ptr);
 
    /*
     * TODO:231:o: |-> copy ipSystemStatsHCInReceives data.
     * get (* ipSystemStatsHCInReceives_val_ptr ).low and (* ipSystemStatsHCInReceives_val_ptr ).high from rowreq_ctx->data
     */
    (*ipSystemStatsHCInReceives_val_ptr).low =
        rowreq_ctx->data->stats.HCInReceives.low;
    (*ipSystemStatsHCInReceives_val_ptr).high =
        rowreq_ctx->data->stats.HCInReceives.high;
 
    return MFD_SUCCESS;
} 
 
 
 
 
 
+          case ASN_COUNTER64:
+       /* We want an integer here */
+       if ((SvTYPE(value) == SVt_IV) || (SvTYPE(value) == SVt_PVMG)) {
+  /* Good - got a real one (or a blessed scalar which we have to hope will turn out OK) */
+  ulltmp = SvIV(value);
+  c64.high = (ulltmp & 0xffffffff00000000ULL) >> 32;
+  c64.low  = (ulltmp & 0xffffffffULL);
+                  snmp_set_var_typed_value(request->requestvb, (u_char)type,
+                                       (u_char *) &c64, sizeof(struct counter64));
+  RETVAL = 1;
+  break;
+       }
+       else if (SvPOKp(value)) {
+           /* Might be OK - got a string, so try to convert it, allowing base 10, octal, and hex forms */
+           stringptr = SvPV(value, stringlen);
+  ulltmp = strtoul( stringptr, NULL, 0 );
+  if (errno == EINVAL) {
+ snmp_log(LOG_ERR, "Could not convert string to number in setValue: '%s'", stringptr);
+ RETVAL = 0;
+ break;
+  }
+
+  c64.high = (ulltmp & 0xffffffff00000000ULL) >> 32;
+  c64.low  = (ulltmp & 0xffffffffULL);
+                  snmp_set_var_typed_value(request->requestvb, (u_char)type,
+                                       (u_char *) &c64, sizeof(struct counter64));
+  RETVAL = 1;
+  break;
+       }

------------------ Original ------------------

From: "Dave Shield"<[email protected]>;

Date: Wed, Jan 27, 2010 06:55 PM

To: "Alexander King"<[email protected]>; 

Cc: "net-snmp-users"<[email protected]>; 

Subject: Re: about net-snmp 64bits data

2010/1/27 Alexander King <[email protected]>:
> You also need to look again at how Counter64 values are handled in the
> Net-SNMP agent. ? Hint:? It's not a simple "long" or "long long" variable.
>
>>>>> I did this:
> and use uint64_t in my c source code,is it right?

No.

Please look at how Counter64 objects are handled elsewhere in the agent.

Dave

------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-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

------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.