[prev in list] [next in list] [prev in thread] [next in thread] 

List:       net-snmp-bugs
Subject:    [ net-snmp-Bugs-2968606 ] truncating integer value > 32 bits
From:       "SourceForge.net" <noreply () sourceforge ! net>
Date:       2010-07-07 17:16:54
Message-ID: E1OWYEw-0003nZ-W3 () sfs-web-9 ! v29 ! ch3 ! sourceforge ! com
[Download RAW message or body]

Bugs item #2968606, was opened at 2010-03-11 11:10
Message generated for change (Comment added) made by rtyle
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112694&aid=2968606&group_id=12694

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: linux
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: aspel (aspel)
Assigned to: Nobody/Anonymous (nobody)
Summary: truncating integer value > 32 bits

Initial Comment:
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"


----------------------------------------------------------------------

Comment By: ross tyler (rtyle)
Date: 2010-07-07 17:16

Message:
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:

            else if (vars->val_len == sizeof(long)){
                *vars->val.integer = clip(*(long *) value);
            }
            else if (vars->val_len == sizeof(long long)){
                *vars->val.integer = clip(*(long long *) value);
            }
            else if (vars->val_len == sizeof(intmax_t)){
                *vars->val.integer = clip(*(intmax_t *) value);
            }



----------------------------------------------------------------------

Comment By: aspel (aspel)
Date: 2010-03-17 13:51

Message:
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

----------------------------------------------------------------------

Comment By: aspel (aspel)
Date: 2010-03-17 13:20

Message:
HOST-RESOURCES-MIB::hrStorageSize.32
.1.3.6.1.2.1.25.2.3.1.5.32

----------------------------------------------------------------------

Comment By: Dave Shield (dts12)
Date: 2010-03-16 15:54

Message:
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

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112694&aid=2968606&group_id=12694

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Net-snmp-bugs mailing list
Net-snmp-bugs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-bugs


[prev in list] [next in list] [prev in thread] [next in thread]