Discussion:
Integer64 support?
(too old to reply)
Turbo Fredriksson
2015-07-09 16:57:06 UTC
Permalink
I've been trying to update my MIB to support the correct value
of some of my pass_persist perl scripts, but I can't seem to get
it to work..

I had to restort to using Integer32 and was hoping for the best, but now
a user have created a ticket about this, so I figured I try again.


Looking at http://sourceforge.net/p/net-snmp/mailman/message/26930463/,
I took that shell script but modified the integer64/counter64 to actually
print a 64bit signed value ("9223372036854775806", which is one below
the max value) but I get some errors in the log:

----- s n i p -----
Connection from UDP: [127.0.0.1]:51594->[127.0.0.1]:161
Internal error in type switching
snmp_build: unknown failuresend response: Error building ASN.1 representation (wrong type in snmp_realloc_rbuild_var_op: 74)
-- iso.3.6.1.4.1.22222.42.2.0
[repeated six times]
----- s n i p -----

The Counter64 value works just fine though (with the same value).


SNMPd is at version 5.7.2.1+dfsg-1. On a older system, with version
5.4.3~dfsg-2.8+deb7u1, it doesn't work at all. Both values gets
truncated to a 32bit int…

Tried 5.7.3+dfsg-1, but that failed as well :(.
--
System administrators motto:
You're either invisible or in trouble.
- Unknown
Bill Fenner
2015-07-10 21:30:14 UTC
Permalink
Can you try this patch?

--- a/agent/mibgroup/ucd-snmp/pass_common.c+++
b/agent/mibgroup/ucd-snmp/pass_common.c
@@ -135,7 +135,7 @@ netsnmp_internal_pass_parse(char * buf,
c64.high = (unsigned long)(v64 >> 32);
c64.low = (unsigned long)(v64 & 0xffffffff);
*var_len = sizeof(c64);- vp->type = ASN_INTEGER64;+
vp->type = ASN_OPAQUE_I64;
return ((unsigned char *) &c64);
}
#endif

Thanks,
Bill
​
Post by Turbo Fredriksson
I've been trying to update my MIB to support the correct value
of some of my pass_persist perl scripts, but I can't seem to get
it to work..
I had to restort to using Integer32 and was hoping for the best, but now
a user have created a ticket about this, so I figured I try again.
Looking at http://sourceforge.net/p/net-snmp/mailman/message/26930463/,
I took that shell script but modified the integer64/counter64 to actually
print a 64bit signed value ("9223372036854775806", which is one below
----- s n i p -----
Connection from UDP: [127.0.0.1]:51594->[127.0.0.1]:161
Internal error in type switching
snmp_build: unknown failuresend response: Error building ASN.1
representation (wrong type in snmp_realloc_rbuild_var_op: 74)
-- iso.3.6.1.4.1.22222.42.2.0
[repeated six times]
----- s n i p -----
The Counter64 value works just fine though (with the same value).
SNMPd is at version 5.7.2.1+dfsg-1. On a older system, with version
5.4.3~dfsg-2.8+deb7u1, it doesn't work at all. Both values gets
truncated to a 32bit int

Tried 5.7.3+dfsg-1, but that failed as well :(.
--
You're either invisible or in trouble.
- Unknown
------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
Net-snmp-users mailing list
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
Turbo Fredriksson
2015-07-11 00:38:13 UTC
Permalink
Post by Bill Fenner
Can you try this patch?
That seems to have worked (applied to 5.7.3+dfsg-1)!

# snmpget -uro -v2c -cpublic localhost .1.3.6.1.4.1.22222.42.2.0 .1.3.6.1.4.1.22222.42.4.0
SNMPv2-SMI::enterprises.22222.42.2.0 = Opaque: Int64: 9223372036854775806
SNMPv2-SMI::enterprises.22222.42.4.0 = Counter64: 9223372036854775806

Now, could I now also ask for advice on how to use that in my MIB?

Should I be using "Integer64" or "Int64"?

This is the current, non-working and wrong section:

zfsPoolSize OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "."
::= { zfsPoolStatusEntry 3 }

https://github.com/FransUrbo/snmp-modules/blob/master/BAYOUR-COM-MIB.txt#L2156-L2161
Turbo Fredriksson
2015-07-13 14:27:44 UTC
Permalink
Post by Bill Fenner
Can you try this patch?
--- a/agent/mibgroup/ucd-snmp/pass_common.c
+++ b/agent/mibgroup/ucd-snmp/pass_common.c
@@ -135,7 +135,7 @@ netsnmp_internal_pass_parse(char * buf,
c64.high = (unsigned long)(v64 >> 32);
c64.low = (unsigned long)(v64 & 0xffffffff);
*var_len = sizeof(c64);
- vp->type = ASN_INTEGER64;
+ vp->type = ASN_OPAQUE_I64;
return ((unsigned char *) &c64);
}
#endif
The user that reported the int64 issue on my agent pointed
out to me that this patch isn't quite right. And not complete…

Since it's checking for a "integer64" in that code, it should
return a "signed char *", no?

And since that and "unsigned" exists, it seems reasonable that
the code should/could return a "unsigned64" as well...

How about the enclosed patch? Tested with the enclosed
test script (a modification on the one I found at an earlier
message - see previous mail in thread):

$ snmpget -uro -v2c -cpublic localhost .1.3.6.1.4.1.22222.42.2.0
SNMPv2-SMI::enterprises.22222.42.2.0 = Opaque: Int64: 9223372036854775806
$ snmpget -uro -v2c -cpublic localhost .1.3.6.1.4.1.22222.42.5.0
SNMPv2-SMI::enterprises.22222.42.5.0 = Gauge32: 4294967294
$ snmpget -uro -v2c -cpublic localhost .1.3.6.1.4.1.22222.42.6.0
SNMPv2-SMI::enterprises.22222.42.6.0 = Opaque: UInt64: 18446744073709551614

Although I'm not sure "Gauge32" is correct, but considering that
it returns the correct value...
Bill Fenner
2015-07-14 06:58:52 UTC
Permalink
Post by Bill Fenner
Can you try this patch?
--- a/agent/mibgroup/ucd-snmp/pass_common.c+++ b/agent/mibgroup/ucd-snmp/pass_common.c
@@ -135,7 +135,7 @@ netsnmp_internal_pass_parse(char * buf,
c64.high = (unsigned long)(v64 >> 32);
c64.low = (unsigned long)(v64 & 0xffffffff);
*var_len = sizeof(c64);- vp->type = ASN_INTEGER64;+ vp->type = ASN_OPAQUE_I64;
return ((unsigned char *) &c64);
}
#endif
The user that reported the int64 issue on my agent pointed
out to me that this patch isn't quite right. And not complete

Since it's checking for a "integer64" in that code, it should
return a "signed char *", no?
No. As with much code that started as pre-ANSI, net-snmp uses (unsigned
char *) to stand in for (void *).
Post by Bill Fenner
And since that and "unsigned" exists, it seems reasonable that
the code should/could return a "unsigned64" as well...
How about the enclosed patch? Tested with the enclosed
test script (a modification on the one I found at an earlier
$ snmpget -uro -v2c -cpublic localhost .1.3.6.1.4.1.22222.42.2.0
SNMPv2-SMI::enterprises.22222.42.2.0 = Opaque: Int64: 9223372036854775806
$ snmpget -uro -v2c -cpublic localhost .1.3.6.1.4.1.22222.42.5.0
SNMPv2-SMI::enterprises.22222.42.5.0 = Gauge32: 4294967294
$ snmpget -uro -v2c -cpublic localhost .1.3.6.1.4.1.22222.42.6.0
SNMPv2-SMI::enterprises.22222.42.6.0 = Opaque: UInt64: 18446744073709551614
Although I'm not sure "Gauge32" is correct, but considering that
it returns the correct value...
SMI defines "Unsigned32" and "Gauge32" identically, so without a MIB loaded
to distinguish, the command-line tool just reports Gauge32 since it has no
way to know.

Bill
Turbo Fredriksson
2015-07-14 12:32:14 UTC
Permalink
No. As with much code that started as pre-ANSI, net-snmp uses (unsigned char *) to stand in for (void *).
Ah, I see. Weird, but… :)
SMI defines "Unsigned32" and "Gauge32" identically, so without a MIB loaded to distinguish, the command-line tool just reports Gauge32 since it has no way to know.
Ok, that make sense.


But how about the other part of the patch?
--
Geologists recently discovered that "earthquakes" are
nothing more than Bruce Schneier and Chuck Norris
communicating via a roundhouse kick-based cryptosystem.
Bill Fenner
2015-07-14 14:29:37 UTC
Permalink
Post by Bill Fenner
No. As with much code that started as pre-ANSI, net-snmp uses (unsigned
char *) to stand in for (void *).
Ah, I see. Weird, but
 :)
SMI defines "Unsigned32" and "Gauge32" identically, so without a MIB
loaded to distinguish, the command-line tool just reports Gauge32 since it
has no way to know.
Ok, that make sense.
But how about the other part of the patch?
Now that we're shining light on this code...

Why is it correct to convert the input to unsigned, and then back to
signed, in the integer64 case? Shouldn't we use strtoll instead of
strtoull for the signed version?

Bill
Turbo Fredriksson
2015-07-14 14:47:19 UTC
Permalink
Why is it correct to convert the input to unsigned, and then back to signed, in the integer64 case? Shouldn't we use strtoll instead of strtoull for the signed version?
No idea. I didn't write the original code or patch :). I have no idea
what's going on at the rest of the code (never really bothered looking :),
I just tried to 'fix' the problem in as simple and non-desruptive way I
could, extending on the patch you gave me (which I saw as partly
wrong and partly missing)…

You have raised a couple of issues, that makes sense, on my patch
but (re)writing it in a way that's perfect and works with the rest of the
code, I leave to someone with more knowledge of the software..
--
You know, boys, a nuclear reactor is a lot like a woman.
You just have to read the manual and press the right buttons
- Homer Simpson

Loading...