Bug 202584

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.

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 216.180.46.38
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 216.180.46.38
truncating integer value to 32 bits
  GETNEXT message
    -- IF-MIB::ifDescr

Sending 50 bytes to 216.180.46.38
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:

request:
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 = 1.3.6.1.2.1.2.2.1.2
002C    0:         NULL
002E     :       }
002E     :     }
002E     :   }
002E     : }

response:
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 = 1.3.6.1.2.1.2.2.1.2.1
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.

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).

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.

Reopening bug at request of submitter.

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;
    }
#endif

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");
        }
#endif

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.

Could this be related or the same bug as:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=208262

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
release.

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.

Michal, thanks for pointing this out. I've tuned the patch according to your
comment, the message goes to LOG_DEBUG now. 

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.

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.

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.

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.

http://rhn.redhat.com/errata/RHBA-2007-0183.html