What is this?

This knowledgebase contains questions and answers about PRTG Network Monitor and network monitoring in general.

Learn more

PRTG Network Monitor

Intuitive to Use. Easy to manage.
More than 500,000 users rely on Paessler PRTG every day. Find out how you can reduce cost, increase QoS and ease planning, as well.

Free Download

Top Tags


View all Tags

Do PRTG and PRTG SNMP Tester support Octet/HEX Strings?

Votes:

1

Hi Paessler Team,

I have been reading the manual and KB regarding this topic and, I found that PRTG MIB Importer only supports Integer values. But is this also valid for PRTG Monitor and PRTG SNMP Tester?

In some of these threads, you mention that in order to request non-integer values I should use the Custom SNMP String sensor. However, I tried that alternative, but the value I got is non-readable characters. I used your SNMP Tester's snmpwalk function but I get the same result.

Just to confirm that I was requesting the correct OID, I used a third-party software to run an snmpwalk test. The values returned were the expected HEX values.

I am trying to monitor a Cisco WLC using the AIRESPACE-WIRELESS-MIB.

The OID is:

Thank you.

cisco hex-value mac-address mib octet-value snmp wireless

Created on Jun 10, 2014 11:00:58 PM

Last change on Mar 3, 2017 11:33:11 AM by Luciano Lingnau [Paessler]



8 Replies

Votes:

0

Dear user

Thank your for using PRTG. PRTG does not support these kinds of strings. Normal strings are supported, but not hexadecimal or octet strings.

Created on Jun 13, 2014 1:29:22 PM by Arne Seifert [Paessler Support]

Last change on Jun 13, 2014 1:31:24 PM by Arne Seifert [Paessler Support]



Votes:

0

Are there plans to add this functionality soon? A huge variety of vendors include some of their most useful information in Hex and Octet strings for some reason. For instance, on a Nimble SAN we would like to monitor the following but cannot with PRTG where we can with other products:

ioReadTimeMicrosec:  OID=.1.3.6.1.4.1.37447.1.3.6.0, Type=Counter64, Value=0x21C981BD93
ioWriteTimeMicrosec:  OID=.1.3.6.1.4.1.37447.1.3.7.0, Type=Counter64, Value=0x3BF37C3EA0
ioReadBytes:  OID=.1.3.6.1.4.1.37447.1.3.8.0, Type=Counter64, Value=0xF96BDE31C00
ioSeqReadBytes:  OID=.1.3.6.1.4.1.37447.1.3.9.0, Type=Counter64, Value=0xEAD468FFA00
ioWriteBytes:  OID=.1.3.6.1.4.1.37447.1.3.10.0, Type=Counter64, Value=0xE9C2AC42A00
ioSeqWriteBytes:  OID=.1.3.6.1.4.1.37447.1.3.11.0, Type=Counter64, Value=0xC0EE822EC00

Created on Jul 1, 2014 9:26:44 PM

Last change on Oct 2, 2015 5:27:42 AM by Luciano Lingnau [Paessler]



Votes:

0

hello,

can you please download our free SNMP Tester

https://www.paessler.com/tools/snmptester

  1. start the tester on your PRTG server
  2. select to use SNMP v2
  3. select Custom OID
  4. and use your OIDs !! lwithout the first dot at the beginning of the OID !!
  5. select Log Raw Packets
  6. then please scan against your device
  7. send the log to [email protected]

please make a reference to this KB article then our developers can take a look at it

Created on Jul 2, 2014 9:34:21 AM by Aurelio Lombardi [Paessler Support]

Last change on Oct 2, 2015 5:28:18 AM by Luciano Lingnau [Paessler]



Votes:

0

Hello,
I have kind of the same problem. I would like to monitor a Juniper device to get a hexadecimal value through snmp-v2. Using your snmp tester it returns me the correct value, for example 10-00-12-34-56-78-9a-bc. Creating a "SNMP Custom String Sensor" with the same OID in PRTG 16.1 and interpreting the value as "Hexadecimal bytes (as in MAC addresses)" gives me the wrong value 10-20-20-20-20-20-20-20.

Log from snmp tester:

02.03.2017 13:45:47 (1 ms) : Device: xxx.xxx.xx.xx
02.03.2017 13:45:47 (1 ms) : SNMP V2c
02.03.2017 13:45:47 (1 ms) : Custom OID 1.3.6.1.2.1.17.2.5.0
02.03.2017 13:45:47 (429 ms) : SNMP Datatype: ASN_OCTET_STR
02.03.2017 13:45:47 (430 ms) : -------
02.03.2017 13:45:47 (430 ms) : Value: 10-00-12-34-56-78-9a-bc
02.03.2017 13:45:47 (431 ms) : Done

From the CLI with "show.." the value is: 10.00.12:34:56:78:9a:bc and from the CLI with the OID instead of the "show..."-command: 10 00 12 34 56 78 9a bc

Am I doing something wrong or is this solved in an actual release?

Created on Mar 2, 2017 3:28:01 PM

Last change on Mar 3, 2017 11:35:15 AM by Luciano Lingnau [Paessler]



Votes:

0

Hello erpdka,
thank you for your KB-Post.

This might be a different situation. Would you mind running a walk of 1.3.6.1.2.1.17.2 against this device(with our SNMP Tester)? Please share the outcome here.

As far as the documentation goes, the OID 1.3.6.1.2.1.17.2.5 refers to dot1dStpDesignatedRoot, which also according to the MIB is an OCTET STRING SIZE(8). This means that it may just be the string with the textual representation of the Mac Address. In this case you should try/use the option:

  • Interpret Result as: String (default): Handle the result as common string.

Please also note that PRTG version 16.1 is rather old. You should update to version 17.1.29 at your earliest convenience.

Best Regards,
Luciano Lingnau [Paessler Support]

Created on Mar 3, 2017 11:45:18 AM by Luciano Lingnau [Paessler]



Votes:

0

Thank you for your feedback. I have tried this with PRTG-Version 17.1.29 using the same OID (1.3.6.1.2.1.17.2.5.0) today and it works fine! The settings (interpret result as hex..) are the same in both versions and in 16.1 I still get the wrong result. Interpreting the result as string gives me some strange characters (for example †) in both versions of PRTG. The outcome of your PRTG-Tester is:

(String)
----------------------- New Test -----------------------
Paessler SNMP Tester 5.2.3 Computername: xx
06.03.2017 14:55:30 (2 ms) : Device: xxx.xxx.xx.xx
06.03.2017 14:55:30 (4 ms) : SNMP V2c
06.03.2017 14:55:30 (5 ms) : Custom OID 1.3.6.1.2.1.17.2.5.0
06.03.2017 14:55:30 (16 ms) : SNMP Datatype: ASN_OCTET_STR
06.03.2017 14:55:30 (18 ms) : -------
06.03.2017 14:55:30 (19 ms) : Value: †
06.03.2017 14:55:30 (59 ms) : Done

(Hex Bytes) --> Correct
----------------------- New Test -----------------------
Paessler SNMP Tester 5.2.3 Computername: xx
06.03.2017 14:55:44 (3 ms) : Device: xxx.xxx.xx.xx
06.03.2017 14:55:44 (5 ms) : SNMP V2c
06.03.2017 14:55:44 (7 ms) : Custom OID 1.3.6.1.2.1.17.2.5.0
06.03.2017 14:55:44 (19 ms) : SNMP Datatype: ASN_OCTET_STR
06.03.2017 14:55:44 (20 ms) : -------
06.03.2017 14:55:44 (22 ms) : Value: 10-00-12-34-56-78-9a-bc
06.03.2017 14:55:44 (26 ms) : Done

We are planning to update our version soon after monitoring our devices with an actual trial licence/version for a few days. Best Regards, Dimitris

Created on Mar 6, 2017 2:18:31 PM

Last change on Mar 6, 2017 2:21:58 PM by Luciano Lingnau [Paessler]



Votes:

0

Hello Dimitris, thank you for your reply.

This confirms that the 1.3.6.1.2.1.17.2.5.0 OID is definitively a Hex-encoded string. In this case the Interpret Result as: Hexadecimal bytes (as in MAC addresses) is indeed the correct option. This was addressed in this specific fix:

APRIL 4TH 2016VERSION 16.2.23.3077/3078
SNMP CUSTOM STRINGSNMP Custom String sensor supports 0 bytes in MAC addresses.

I'm glad to hear that it worked out for you.

Best Regards,
Luciano Lingnau [Paessler Support]

Created on Mar 7, 2017 8:29:33 AM by Luciano Lingnau [Paessler]



Votes:

1

Dear readers.

I've been using PRTG for almost two decades and have more often come across this problem in the later years. I find it odd that Paessler still haven't solved this. I agree with Blake in the second reply of this thread. Many vendors supply information on this way and it should be very easy to implement this in PRTG code.

This is the response I get from a device and it is crusal that we can monitor this timestamp. Unfortunately, we still can't use PRTG for that purpose.

----------------------- New Test ----------------------- Paessler SNMP Tester 5.2.3 Computername: PRTG Interface: (x.x.x.x) 01.04.2019 22:54:26 (5 ms) : Device: x.x.x.x 01.04.2019 22:54:26 (8 ms) : SNMP V2c 01.04.2019 22:54:26 (10 ms) : Custom OID 1.3.6.1.4.1.9.9.388.1.3.1.1.4.474 01.04.2019 22:54:26 (21 ms) : SNMP Datatype: ASN_OCTET_STR 01.04.2019 22:54:26 (23 ms) : ------- 01.04.2019 22:54:26 (25 ms) : Value: 07-E3-03-1B-01-11-2F-00 01.04.2019 22:54:26 (28 ms) : Done

Regards...

Created on Apr 1, 2019 9:12:21 PM




Disclaimer: The information in the Paessler Knowledge Base comes without warranty of any kind. Use at your own risk. Before applying any instructions please exercise proper system administrator housekeeping. You must make sure that a proper backup of all your data is available.