Description of problem: RH4U4/ia64 shows an interesting problem when you try to lookup negative numbers via snmp. Here is an example. The value of tcpMaxConn.0 should be -1. Instead what happens is we get the truncating message then we end up with a very,very big value (looks like an inverted value): [root@bake snmp]# snmpget -v 1 bake -c public tcpMaxConn.0 truncating integer value to 32 bits TCP-MIB::tcpMaxConn.0 = INTEGER: 4294967295 [root@bake snmp]# Now on rh4u2 on the same platform shows this correctly: [root@simmer ~]# snmpget -v 1 simmer -c public tcpMaxConn.0 TCP-MIB::tcpMaxConn.0 = INTEGER: -1 [root@simmer ~]# Something has changed between u2 and u4 to break this. Version-Release number of selected component (if applicable): How reproducible: Lookup any snmp value that is negative (as shown above). Steps to Reproduce: 1. Configure snmp 2. use snmpwalk or snmpget to dump the mip components Actual results: [root@bake snmp]# snmpget -v 1 bake -c public tcpMaxConn.0 truncating integer value to 32 bits TCP-MIB::tcpMaxConn.0 = INTEGER: 4294967295 [root@bake snmp]# Expected results: [root@simmer ~]# snmpget -v 1 simmer -c public tcpMaxConn.0 TCP-MIB::tcpMaxConn.0 = INTEGER: -1 [root@simmer ~]# Additional info: This has to be some kind of configuration or other such issue. There has to be an easy way around this, I would think.
FYI: It would appear that this coming from asn_parse_unsigned_int64() routine in the file asn1.c: *datalength -= (int) asn_length + (bufp - data); if (*bufp & 0x80) value = ~value; /* integer is negative */ DEBUGDUMPSETUP("recv", data, bufp - data + asn_length); while (asn_length--) value = (value << 8) | *bufp++; #if SIZEOF_LONG != 4 if (value > 0xffffffff) { snmp_log(LOG_ERR,"truncating uinteger value to 32 bits\n"); value &= 0xffffffff; } #endif This is directly from the net-snmp-5.1.2-11.EL4.7.src.rpm from the rh4U4 distro. This code has been changed quite a bit in this area and looks like overflow and the like is checked for differently which is why this problem is not seen in this version.
This bug will be fixed in RHEL4.5. The issue is already known and fixed. *** This bug has been marked as a duplicate of 211457 ***