On Jul 10, 2015, at 11:30 PM, Bill Fenner wrote: 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... |
int64_to_i64.patch
Description: Binary data
pptest.sh
Description: Binary data
------------------------------------------------------------------------------ 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 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