Created attachment 364246 [details] Patch to apply when building net-snmp RPM When on a 64-bit operating system, the following error occurs occasionally when reading integers: truncating unsigned value to 32 bits (2) A patch was already created on the net-snmp library: http://sourceforge.net/apps/trac/net-snmp/changeset/16762 I will attach a patch file to include in the RPM for net-snmp that fixes the problem.
Created attachment 366699 [details] JAR file for reproducible test case This is a hard bug to reproduce. A device has to respond with a large unsigned integer such that the first bit is a "1". I am attaching a Java JAR file that will listen for incoming requests for a certain OID on UDP port 1161, responding with a value that is known to reproduce the bug. In one window, run: java -jar ./snmpbug.jar In another window, run: snmpget -c public -v 1 localhost:1161 ifInOctets.3 On a RHEL box that is affected by this bug, you will see: truncating unsigned value to 32 bits (2) IF-MIB::ifInOctets.3 = Counter32: 3350619650 On a patched box, this error message does not appear.
Thanks for the reproducer! There is something weird about it - either the message it sends is not correct or the parsing in snmpget is wrong. What SNMP agent sends such responses? Is it Net-SNMP? The patch you propose just hides the error, I am not sure it is the right thing to do. Of course, the patch is correct and is from upstream, so I have no problems applying it as last resort. I'll dig into ASN.1 specifications to find out if the packet is correct. And the usual disclaimer at the end: Bugzilla is not a support tool. If you are Red Hat Enterprise Linux subscriber, please visit redhat.com/support to get the service you pay for. Bugs without support ticket have lower priority.
(In reply to comment #2) > I'll dig into ASN.1 specifications to find out if the packet is correct. So, ISO/IEC 8825-1:2003 (ASN.1 Basic Encoding Rules) specifies, that Counter32 (=INTEGER) value shall be encoded as two's complement binary number. Your reproducer sends 'C7 B6 66 02' (=0xC7B66602) as value of ifInOctets.3, which means the value is negative (the highest bit of C7 is sign and it's '1'). This negative number is then processed by snmpget and interpreted as unsigned long 0xFFFFFFFFC7B66602, which is bigger than Counter32 can hold -> error is shown. snmpget shows correct counter value just by coincidence (it cuts the unsigned long to 32 bits). The correct way how to send such number is '00 C7 B6 66 02' (note the additional leading byte). I think you should get your SNMP agent fixed first, we don't achieve much by hiding the error message.
Jan - Thanks for your note. I do have a support ticket open, #1965586. I agree that our agent is misbehaving. In fact, that's why I had to build a custom responder! Unfortunately, we're dealing with very old legacy network switches, whose manufacturer has long since stopped releasing new software. And since we monitor them via our website, these errors are filling up our Apache error logs. Fortunately, we're replacing the switches over the coming months. So I'm totally okay with turning the other way while NET-SNMP complains. But if the upstream source decided to ignore the message, wouldn't it be okay to do so in the RPM as well? Let me know what you think, thanks! Norman
The bug should be fixed in net-snmp-5.3.2.2-8.
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 therefore 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-2010-0253.html