Your message dated Fri, 8 Dec 2017 10:35:46 +0100
with message-id <[email protected]>
and subject line Re: Bug#189263: libnet-snmp-perl: Module treats counter32 
values as signed integers, produces wrong results.
has caused the Debian Bug report #189263,
regarding libnet-snmp-perl: Module treats counter32 values as signed integers, 
produces wrong results.
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)


-- 
189263: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=189263
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: libnet-snmp-perl
Version: 3.6-7
Severity: important

The module will produce completely the wrong data in some circumstances. A test
case is show below:-

./scalar_fetch.pl ; ./array_fetch.pl 
Host: 192.168.1.14; OID: .1.3.6.1.2.1.2.2.1.16.119; Value: 3508114820
Host: 192.168.1.14; OID: .1.3.6.1.2.1.2.2.1.10.119; Value: 999049505
SNMP session to 194.81.120.14 established with community public
Key: .1.3.6.1.2.1.2.2.1.16.119; value 786852476
Key: .1.3.6.1.2.1.2.2.1.10.119; value 999049505

These two scripts should produce identical results, but as is clearly visible,
the value of the first OID is wrong when called from the "array_fetch.pl" code.

Filing this bug as serious as it effectively makes the module unusable for
retrieving network stats from COUNTER32 values under some circumstances.

The bug appears to be occurring in the _asn1_decode_integer32 routine, which is
called for COUNTER32 data. This is incorrectly treating 32 bit counters with
the top bit set as negative, but only when the get_request() method is passed
an array. The bug ius entirely reproducible on two separate machines here,
looking at different network hardware. Packet traces have verified that the
data returned from the SNMP request is correct. The error is occurring in
/usr/share/perl5/Net/SNMP.pm at around this point:-

if ($negative) {
   sprintf("%d", $integer);
} else {
   $integer = abs($integer);
   sprintf("%u", $integer);
}


Source for the two test programs that show the problem:-

./scalar_fetch.pl
==============================================================
#!/usr/bin/perl

use Net::SNMP;

$community = "public";                  # SNMP community with read access

$host = "192.168.1.14";
$oid = ".1.3.6.1.2.1.2.2.1.16.119";

($session, $error) = Net::SNMP->session(
                        -hostname => $host,
                        -community => $community);
                                                        
die "Error instantiating SNMP object; $error\n" unless $session;
                                                                

$response = $session->get_request($oid);
print "Host: $host; OID: $oid; Value: $response->{$oid}\n";
$oid = ".1.3.6.1.2.1.2.2.1.10.119";
$response = $session->get_request($oid);
print "Host: $host; OID: $oid; Value: $response->{$oid}\n";

$session->close();

==============================================================

array_fetch.pl
==============================================================
#!/usr/bin/perl -T
#
our %snmp = ("192.168.1.14"    =>      [ "public",
                                          [ ".1.3.6.1.2.1.2.2.1.10.119",
                                            ".1.3.6.1.2.1.2.2.1.16.119" ]
                                        ]
            );

$ENV{PATH}="/bin:/usr/bin";

use Net::SNMP;


# Takes an appropriately formatted hash, with snmp agent names/addresses
# and OIDs required, gets the OID values, and returns references to a
# similarly formatted hash, containing the SNMP provided values.

my ($session, $error, $response, @responses, %snmpdata, %oids);

%oids = %snmp;

foreach $host (keys %oids) {
        ($session, $error) = Net::SNMP->session(
                                -hostname => $host,
                                -community => $oids{$host}->[0]);

        die "Error instantiating SNMP object; $error\n" unless $session;
        print "SNMP session to $host established with community 
$oids{$host}->[0]\n";
        $response = $session->get_request(@{$oids{$host}->[1]});
        if ($response) {
                foreach (keys %$response) {
                        print "Key: ${_}; value $$response{$_}\n";
                }
        } else {
                print "Error for host $host\n";
        }

        $session->close;
        print "SNMP session to $host closed\n";
}

-- System Information
Debian Release: 3.0
Kernel Version: Linux castor 2.4.20-xfs #1 SMP Sun Feb 2 16:58:42 GMT 2003 i686 
unknown

Versions of the packages libnet-snmp-perl depends on:
ii  perl           5.6.1-8.2      Larry Wall's Practical Extraction and Report


--- End Message ---
--- Begin Message ---
Source: libnet-snmp-perl
Source-Version: 6.0.1-2

On Di, 22 Aug 2017, Roland Rosenfeld wrote:

> On Mi, 16 Apr 2003, [email protected] wrote:
> 
> > The bug appears to be occurring in the _asn1_decode_integer32
> > routine, which is called for COUNTER32 data. This is incorrectly
> > treating 32 bit counters with the top bit set as negative, but only
> > when the get_request() method is passed an array.
> 
> As far as I can see, this issue was solved a long time ago upstream:
> 
> | RELEASE 3.65 SEP-09-2001
> | 
> | - Counter, Gauge, and TimeTick values that are incorrectly encoded as
> |   negative signed integers are now converted to unsigned values.  This
> |   feature can be disabled by setting the "-unsigned" flag to false 
> |   using the translate() method.
> 
> Please check, whether this really solves this issue for you.
> I tend to close this issue otherwise.

Since nobody objected, I think that this issue is solved, so I close
this bug report.
If you still observe the problem, just reopen the ticket.

Greetings
Roland

Attachment: signature.asc
Description: PGP signature


--- End Message ---

Reply via email to