[mrtg] SNMP_util.pm problem

Tue Dec 9 07:09:46 CET 2014

Hello Mike,

Indeed, "use Net_SNMP_util"  solved my issue.
Thx for explaining  how this issue occurs and how to solve it.

Knowing this, I wonder how MRTG, that is using these SNMP libs, is dealing with this kind of data.  I guess not in the correct way.

Kind Regards and have a great day

Marc Engrie

From: Mike Mitchell [mailto:Mike.Mitchell at sas.com]
Sent: Monday, December 08, 2014 10:24 PM
To: Marc Engrie
Subject: RE: SNMP_util.pm problem

I don't believe this is a problem with SNMP_util.pm

If we compare the two returned values, the "working" one ends with

04 01 30

and the "non-working" one ends with

42 05 00 ff ff ff ff

These are BER-encoded values. BER encoding starts with a data-type byte, then a length byte, followed by the data. A data-type of '04' is an octet-string, in other words a series of ASCII-printable bytes. So '04 01 30' says 'a one-byte string, hex 30'. Hex 30 is ascii '0'.

A data-type of 42 is "Application integer". So '42 05 00 ff ff ff' says 'an integer, five bytes long, value 0x00ffffff'.

No wonder you get different values printed. The two are in different data formats.

SNMP_util.pm is just a wrapper for SNMP_Session.pm. It is SNMP_Session.pm and BER.pm that are doing all the work.

There is also Net_SNMP_util.pm, with the exact same API as SNMP_util.pm. You could try using Net_SNMP_util.pm by just replacing the "use SNMP_util" line with "use Net_SNMP_util". Net_SNMP_util.pm is a wrapper for Net::SNMP, a different implementation of SNMP. You'll have to install the Net::SNMP perl module if you haven't already.

Mike Mitchell

________________________________
From: mrtg <mrtg-bounces+mike.mitchell=sas.com at lists.oetiker.ch<mailto:mrtg-bounces+mike.mitchell=sas.com at lists.oetiker.ch>> on behalf of Marc Engrie <marc.engrie at sanoma.com<mailto:marc.engrie at sanoma.com>>
Sent: Monday, December 8, 2014 1:40 AM
To: mrtg at lists.oetiker.ch<mailto:mrtg at lists.oetiker.ch>
Subject: [mrtg] SNMP_util.pm problem

Hello,

I have been using MRTg and related lib for year now without problems but now I come against something strange and my guess is it is due to 64 bit integers.
I have been using the SNMP informant tool up to version 2013 without issues to query Windows machines for several info's.  2013 was 32 bit oriented. The new version, 2014, is 64bit oriented.

When I use SNMP_util (version 1.15) in my own Perl scripts to query the CPU instances it returns me up nicely all instances when query is against version 2013.
Eg.

$VAR1 = [for CPU's ...
          '1.48:0',
          '1.49:1',
          '6.95.84.111.116.97.108:_Total'
        ];

When I use SNMP_util to query the CPU instances it returns me higher values when query is against version 2014.

$VAR1 = [for CPU's ...
          '1.48:4294967295',
          '1.49:4294967295',
          '6.95.84.111.116.97.108:4294967295'
        ];

One would think that the problem is due to SNMP Informant but when I use  GetIf, or Mib Browser from MG-soft  or Mib Browser from ManageEngine, they all return me the 'right' values: 0, 1, ...

Using ManageEngine, one can debug the data and there I see that the return packet from the 2013 look like this

Sent Type: GET. RequestID: 54 to "10.2.144.33:161".
Sent Time: Mon Dec 01 09:09:06:748 CET 2014
Length of SNMP DATA: 40
DATA
30 26 02 01 00 04 06 70 75 62 6c 69 63 a0 19 02 01 36 02 01
00 02 01 00 30 0e 30 0c 06 08 2b 06 01 02 01 01 02 00 05 00
Sent Type: GETNEXT. RequestID: 55 to "10.2.144.33:161".
Sent Time: Mon Dec 01 09:09:06:748 CET 2014
Length of SNMP DATA: 44
DATA
30 2a 02 01 00 04 06 70 75 62 6c 69 63 a1 1d 02 01 37 02 01
00 02 01 00 30 12 30 10 06 0c 2b 06 01 04 01 cb 00 01 02 41
01 01 05 00

Packet from: 10.2.144.33:161 RequestID: 54
Received Time: Mon Dec 01 09:09:06:748 CET 2014
Length of SNMP DATA: 52
DATA:
30 32 02 01 00 04 06 70 75 62 6c 69 63 a2 25 02 01 36 02 01
00 02 01 00 30 1a 30 18 06 08 2b 06 01 02 01 01 02 00 06 0c
2b 06 01 04 01 82 37 01 01 03 01 02

Packet from: 10.2.144.33:161 RequestID: 55
Received Time: Mon Dec 01 09:09:07:622 CET 2014
Length of SNMP DATA: 47
DATA:
30 2d 02 01 00 04 06 70 75 62 6c 69 63 a2 20 02 01 37 02 01
00 02 01 00 30 15 30 13 06 0e 2b 06 01 04 01 cb 00 01 02 41
01 01 01 30 04 01 30

 While looking at a 2014 result it looks like

Sent Type: GET. RequestID: 49 to "10.2.144.155:161".
Sent Time: Mon Dec 01 09:08:34:673 CET 2014
Length of SNMP DATA: 40
DATA
30 26 02 01 00 04 06 70 75 62 6c 69 63 a0 19 02 01 31 02 01
00 02 01 00 30 0e 30 0c 06 08 2b 06 01 02 01 01 02 00 05 00
Sent Type: GETNEXT. RequestID: 50 to "10.2.144.155:161".
Sent Time: Mon Dec 01 09:08:34:673 CET 2014
Length of SNMP DATA: 44
DATA
30 2a 02 01 00 04 06 70 75 62 6c 69 63 a1 1d 02 01 32 02 01
00 02 01 00 30 12 30 10 06 0c 2b 06 01 04 01 cb 00 01 02 41
01 01 05 00

Packet from: 10.2.144.155:161 RequestID: 49
Received Time: Mon Dec 01 09:08:34:673 CET 2014
Length of SNMP DATA: 52
DATA:
30 32 02 01 00 04 06 70 75 62 6c 69 63 a2 25 02 01 31 02 01
00 02 01 00 30 1a 30 18 06 08 2b 06 01 02 01 01 02 00 06 0c
2b 06 01 04 01 82 37 01 01 03 01 02

Packet from: 10.2.144.155:161 RequestID: 50
Received Time: Mon Dec 01 09:08:34:689 CET 2014
Length of SNMP DATA: 51
DATA:
30 31 02 01 00 04 06 70 75 62 6c 69 63 a2 24 02 01 32 02 01
00 02 01 00 30 19 30 17 06 0e 2b 06 01 04 01 cb 00 01 02 41
01 01 01 30 42 05 00 ff ff ff ff

And there I see that an extra  ff ff ff ff  is return which SNMP_util interpretes in a different way.

Is there a way to tell SNMP_util that it needs to handle this kind of data as 64 bit integer, as I guess this is a 64 bit integer) and not as something else?

Thx for helping me to solve this puzzle of 32 & 64 bit stuff.

Kind regards

Marc Engrie
ICT Infrastructure Manager
Tel: +32 15 67 8398
GSM: +32 476 52 35 45

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.oetiker.ch/pipermail/mrtg/attachments/20141209/f5b44683/attachment-0001.html>