Bug 202584 - "truncating integer value to 32 bits"
"truncating integer value to 32 bits"
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: net-snmp (Show other bugs)
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Radek Vokal
: Regression, Reopened
Depends On:
  Show dependency treegraph
Reported: 2006-08-15 06:54 EDT by Chris Adams
Modified: 2007-11-16 20:14 EST (History)
5 users (show)

See Also:
Fixed In Version: RHBA-2007-0183
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-05-01 13:28:46 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Chris Adams 2006-08-15 06:54:34 EDT
When fetching the interface counters via snmpd, a short time after the system is
booted or snmpd is restarted, the fetch fails and snmpd writes in

truncating integer value to 32 bits

This is with net-snmp-5.1.2-11.EL4.7.  I have downgraded to
net-snmp-5.1.2-11.EL4.6 and do not see the problem.  I only see this on my
x86_64 server, not my i386 server.

I see in the changelog "return inInOctets/ifOutOctets properly (#175536)", but
that bug is private.
Comment 1 Radek Vokal 2006-08-21 09:16:24 EDT
This is fix for 64bit spefic issue. Counter32 values show zero without this
patch, so they are truncated on server side. The Counter32 patch is for Bug #158630.
Comment 2 Chris Adams 2006-08-21 10:51:33 EDT
There _is_ a bug (or more than one).

The log should not be spammed with the "truncating integer value to 32 bits"
message.  A server that is monitored via SNMP gets tons of these messages. 
Also, the message is useless since it doesn't tell the affected OID.

Second, there is something broken about the changes between 11.EL4.6 and
11.EL4.7.  With the old version, monitoring x86_64 server interface traffic with
Cricket via SNMP works; with the new version, it does not.

Looking at the net-snmp-5.1.2-counter32.patch source, there must be something
wrong happening anyway.  The patch to interfaces.c silently truncates the
interface octets and packets counters to 32 bits; only the patch to asn.1.c logs
a message when truncating.  However, I'm getting the message logged when
fetching interface stats (Cricket fetches ifInOctets, ifOutOctets, ifInErrors,
ifOutErrors, ifInUcastPkts, ifOutUcastPkts, and ifDescr).  The errors are 0, so
the message must be coming when octets or packets are being truncated.

Also, with snmpd -d running, I get the "truncating" message even when I don't
request any value that _can_ be truncated, such as when requesting ifDescr (I've
XXed out my community string here):

Received 46 bytes from
0000: 30 2C 02 01  00 04 08 XX  XX XX XX XX  XX XX XX A1    0,.....XXXXXXXX.
0016: 1D 02 04 E4  CD 2A 99 02  01 00 02 01  00 30 0F 30    .....*.......0.0
0032: 0D 06 09 2B  06 01 02 01  02 02 01 02  05 00          ...+..........

Received SNMP packet(s) from
truncating integer value to 32 bits
  GETNEXT message
    -- IF-MIB::ifDescr

Sending 50 bytes to
0000: 30 30 02 01  00 04 08 XX  XX XX XX XX  XX XX XX A2    00.....XXXXXXXX.
0016: 21 02 05 00  E4 CD 2A 99  02 01 00 02  01 00 30 12    !.....*.......0.
0032: 30 10 06 0A  2B 06 01 02  01 02 02 01  02 01 04 02    0...+...........
0048: 6C 6F                                                 lo

Could the problem be that the request ID is getting munged by the change in
asn1.c?  The above request ID is (as a 32 bit number) negative, but the patch to
asn1.c casts integers as unsigned long.  That would cause the response to get
ignored.  When I decode the packets with perl's Convert::ASN1::asn_dump()
function, I get:

0000   44: SEQUENCE {
0002    1:   INTEGER = 0
0005    8:   STRING = '6cewv6ya'
000F   29:   [CONTEXT 1] {
0011    4:     INTEGER = -456316263
0017    1:     INTEGER = 0
001A    1:     INTEGER = 0
001D   15:     SEQUENCE {
001F   13:       SEQUENCE {
0021    9:         OBJECT ID =
002C    0:         NULL
002E     :       }
002E     :     }
002E     :   }
002E     : }

0000   48: SEQUENCE {
0002    1:   INTEGER = 0
0005    8:   STRING = '6cewv6ya'
000F   33:   [CONTEXT 2] {
0011    5:     INTEGER = 3838651033
0018    1:     INTEGER = 0
001B    1:     INTEGER = 0
001E   18:     SEQUENCE {
0020   16:       SEQUENCE {
0022   10:         OBJECT ID =
002E    2:         STRING = 'lo'
0032     :       }
0032     :     }
0032     :   }
0032     : }

The request IDs have the same binary representation, but one is 4 bytes and the
other is 5.
Comment 3 Chris Adams 2006-08-21 10:55:30 EDT
FYI: I tried to reopen the bug, but I got "You tried to change the Status field
from CLOSED to NEW, but only the owner or submitter of the bug, or a
sufficiently empowered user, may change that field." from Bugzilla (despite
being the submitter).
Comment 4 Chris Adams 2006-08-22 14:34:01 EDT
I did some additional testing, and the negative request ID is definately the
problem.  I'm using the perl SNMP_Session module (from
ftp://ftp.switch.ch/software/sources/network/snmp/perl/, also in Fedora Extras).
 SNMP_Session.pm has the option:

  ### Default value for "avoid_negative_request_ids".
  ### Set this to non-zero if you have agents that have trouble with
  ### negative request IDs, and don't forget to complain to your agent
  ### vendor.  According to the spec (RFC 1905), the request-id is an
  ### Integer32, i.e. its range is from -(2^31) to (2^31)-1.  However,
  ### some agents erroneously encode the response ID as an unsigned,
  ### which prevents this code from matching such responses to requests.
  $SNMP_Session::default_avoid_negative_request_ids = 0;

Something in the net-snmp changes between RHEL 4.3 and 4.4 broke this handling,
and it appears to be related to the attempts to truncate integers to 32 bits
(since that message is logged when the problem occurs).

Please let me know if you need further debugging.  I don't currently have an
x86_64 RHEL test system though, so I am unable to test changes to net-snmp source.
Comment 5 David Lawrence 2006-08-22 14:44:25 EDT
Reopening bug at request of submitter.
Comment 6 Chris Adams 2006-08-24 16:27:44 EDT
The problem is that the code in snmplib/asn1.c, function asn_parse_int() includes:

#if SIZEOF_LONG != 4
    if ((unsigned long)value > 0xffffffff) {
        snmp_log(LOG_ERR,"truncating integer value to 32 bits\n");
        value &= 0xffffffff;

That is only correct for positive values.  Integers can be negative, which would
need code something like:

#if SIZEOF_LONG != 4
        if ((long) value > 0x7fffffff) {
                value &= 0x7fffffff;
                snmp_log(LOG_ERR,"truncating integer value to 32 bits\n");
        } else if ((long) value < (-1 * 0x7fffffffL)) {
                value = -1 * ((value * -1) & 0x7fffffff);
                snmp_log(LOG_ERR,"truncating negative integer value to 32 bits\n");

However, I'm not sure if the code is only called for values that can be signed.
 If so, it will take a much bigger change to the code to fix it.
Comment 7 Sharif Nassar 2006-10-09 21:35:52 EDT
Could this be related or the same bug as:

Comment 11 RHEL Product and Program Management 2006-11-20 09:23:09 EST
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
Comment 12 Michal Marciniszyn 2006-11-22 06:25:46 EST
As posted in comment #2, the snmpd spams the log. The reason is, that the
message is logged into the LOG_ERROR, while it should be in the LOG_DEBUG (or
some other appropriate log level), as the truncation is not an error, but
neccessary feature due to different integer sizes on 32bit and 64bit archs.
Comment 13 Radek Vokal 2006-11-22 08:12:14 EST
Michal, thanks for pointing this out. I've tuned the patch according to your
comment, the message goes to LOG_DEBUG now. 
Comment 14 Chris Adams 2006-11-22 09:07:15 EST
Truncation IS an error, because it is being done incorrectly.  See the traces I
posted; an unsigned 32 bit integer that is greater than 2^31 (has the highest
bit set) is converted into a 40 bit integer on the wire, and that is invalid.
Comment 16 RHEL Product and Program Management 2006-12-12 12:09:13 EST
This bugzilla has Keywords: Regression.  

Since no regressions are allowed between releases, 
it is also being marked as a blocker for this release.  

Please resolve ASAP.
Comment 17 RHEL Product and Program Management 2006-12-12 12:10:25 EST
This bugzilla has Keywords: Regression.  

Since no regressions are allowed between releases, 
it is also being marked as a blocker for this release.  

Please resolve ASAP.
Comment 21 Red Hat Bugzilla 2007-05-01 13:28:46 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


Note You need to log in before you can comment on or make changes to this bug.