NET-SNMP version: 5.5
configure-options '--prefix=/usr' '--without-rpm'
Linux 2.6.32-trunk-amd64 #1 SMP Sun Jan 10 22:40:40 UTC 2010 x86_64
On the server I have 22Tb storage,
/dev/sda1 22T 5.3T 17T 25% /storage
when I try get size of /storage using snmpwalk, result was only 6Tb and in logs "truncating integer value > 32 bits"
Which MIB objects are you looking at?
v5.5 introduced a new set of paired objects
dsk{Total,Avail,Used}{High,Low} to handle large disks.
The older dsk{Total,Used,High} objects are fundamentally
limited to 32-bit values, and will latch at a maximum 6Tb
HOST-RESOURCES-MIB::hrStorageSize.32
.1.3.6.1.2.1.25.2.3.1.5.32
snmpwalk -v 2c -c public localhost .1.3.6.1.2.1.25.2.3.1.5.32
result:
HOST-RESOURCES-MIB::hrStorageSize.32 = INTEGER: 1555565047
snmp.log:
truncating integer value > 32 bits
In any case, the truncation code in snmp_client.c is incorrect.
On a 64-bit machine, a long 0x00000001 80000000 is truncated to 0x00000000 80000000.
This is BER encoded as a 5 byte integer (02 05 00 80 00 00 00) which is not accepted by some 32bit SNMP clients.
Even worse, a -1 (0xFFFFFFFF FFFFFFFF) is truncated to 0x00000000 FFFFFFFF an BER encoded to 02 05 00 FF FF FF FF).
Truncation is wrong.
Narrowing to 32 bits should be done with respect to sign and magnitude by clipping the value to a narrower range.
0x00000001 80000000 should be clipped to 0x00000000 7FFFFFFF (and BER encoded to 02 04 7F FF FF FF).
0xFFFFFFFF FFFFFFFF should be clipped to 0x00000000 FFFFFFFF (and BER encoded to 02 04 FF FF FF FF).
For example,
/*
* If necessary, clip a value of the largest integer type
* to the range supported by the default integer type
* and log an error message.
* Returns the (clipped?) input value as a long integer type.
*/
static long clip(intmax_t i)
{
if (i > INT_MAX) {
snmp_log(LOG_ERR,"clipping integer value > INT_MAX\n");
return INT_MAX;
}
if (i < INT_MIN) {
snmp_log(LOG_ERR,"clipping integer value < INT_MIN\n");
return INT_MIN;
}
return i;
}
The snmp_client.c code simplifies to something like this: