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:[email protected]] 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 <[email protected]<mailto:[email protected]>> on behalf of Marc Engrie <[email protected]<mailto:[email protected]>> Sent: Monday, December 8, 2014 1:40 AM To: [email protected]<mailto:[email protected]> 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
_______________________________________________ mrtg mailing list [email protected] https://lists.oetiker.ch/cgi-bin/listinfo/mrtg
