Certain return types do not get interpeted correctly in walks

[Guyverix]

I have begun testing with your example, and the walks are going really well, now that I installed GMP and it can handle the 64 bit counters correctly. However I am currently seeing issues where a return is a Hex-STRING value, and the returns get mangled.

snmpwalk -v2c -c noyb 192.168.15.58 1.3.6.1.2.1.92.1.3.1.1.3.7.100.101.102.97.117.108.116.1
iso.3.6.1.2.1.92.1.3.1.1.3.7.100.101.102.97.117.108.116.1 = Hex-STRING: 07 E5 0C 11 0A 19 36 00 2D 08 00 

From the walk example:

1.3.6.1.2.1.92.1.3.1.1.3.7.100.101.102.97.117.108.116.1 = �

6-

Another using the example code:

1.3.6.1.2.1.55.1.5.1.8.2 = 8�G��}

manually:

snmpwalk -v2c -c noyb 192.168.15.58 1.3.6.1.2.1.55.1.5.1.8.2
iso.3.6.1.2.1.55.1.5.1.8.2 = Hex-STRING: 38 D5 47 DF DA 7D 

Is there additional information that I can provide to assist in debugging this? Ubuntu 20.04 PHP 7.4.26

[Guyverix]

Did a var dump to assist in debugging this, and found this:

            [96] => FreeDSx\Snmp\Oid Object
                (
                    [oid:protected] => 1.3.6.1.2.1.92.1.3.1.1.3.7.100.101.102.97.117.108.116.1
                    [value:protected] => FreeDSx\Snmp\Value\StringValue Object
                        (
                            [value:protected] => �

6-
                        )

                    [status:protected] => 
                )

[ChadSikorra]

I imagine it gets mangled as the hex string represents some kind of binary output, and trying to echo that will not work very well. Though I have not worked much in this library since changing jobs and everything a couple times...hah. I would have to dig in more to see if I'm doing something wrong here in code.

[Guyverix]

If ( and it is a big if) I am reading the code correctly, the TAG_TYPE_OCTET_STRING = 0xFF; may be the culprit. I think I understand a little how to glued this together, and believe it needs a TAG_TYPE_HEX_STRING = 0x??; written that does not change the returned values.

Unfortunately I am still at the tinker-toy level when writing PHP, and not sure where else I can dig in here to assist more. It appears that your FreeDSx\Snmp\Value\StringValue file already has the value transformed when it receives it in the __construct function, and I am not really able to follow backwards more on this very well.

I THINK it is received from the FreeDSx\Asn1\Type\OctetStringType and that is what is mangling the value. Is there any way to simply make any untagged values simply return the string data from SNMP unaltered? I am assuming OCTET_STRING is a catchall since this type is actually identified as hex-STRING according to Net-SNMP output.

[ChadSikorra]

This is really a consequence of me not having MIB parsing / SMIv2 support in this library. How to interpret a hex string is determined by the MIB definition it came from. So this library is just throwing you the raw value without any assumptions about how to interpret it.

What is the value that is printed if, in this case, you wrapped the OID value in a bin2hex? ie:

echo bin2hex($oid->getValue());

Edit: For reference, the possible value types are defined in the RFC here -- https://datatracker.ietf.org/doc/html/rfc3416#section-2.5 . Been a while since I've worked on SNMP, so still trying to remember what I was doing here.

[Guyverix]

The bin2hex looks like it is translating the value back to a string correctly in the case of Hex-String

php ./pollerTest.php -h 192.168.15.58 -v 2 -c noyb -o 1.3.6.1.2.1.88.1.4.2.1.3.6.95.115.110.109.112.100.95.108.105.110.107.68.111.119.110
1.3.6.1.2.1.88.1.4.2.1.3.6.95.115.110.109.112.100.95.108.105.110.107.68.111.119.110 == �
bin2hex: 80

So the bin2hex returns what was expected for that value, but this one is also not returning as well and it is type Opaque?

php ./pollerTest.php -h 192.168.15.58 -v 2 -c noyb -o 1.3.6.1.4.1.2021.10.1.6.1
1.3.6.1.4.1.2021.10.1.6.1 == �x>\
bin2hex 9f78043ec28f5c

            [37] => FreeDSx\Snmp\Oid Object
                (
                    [oid:protected] => 1.3.6.1.4.1.2021.10.1.6.1
                    [value:protected] => FreeDSx\Snmp\Value\ArbitraryValue Object
                        (
                            [value:protected] => �x>��H
                        )

                    [status:protected] => 
                )

snmpwalk -v2c -c noyb 192.168.15.58 1.3.6.1.4.1.2021.10.1.6.1
iso.3.6.1.4.1.2021.10.1.6.1 = Opaque: Float: 0.230000

[Guyverix]

Is there a way to do some kind of fall through so that the raw data is simply returned without manipulation if it does not follow the mapped types?

[ChadSikorra]

Is there a way to do some kind of fall through so that the raw data is simply returned without manipulation if it does not follow the mapped types?

That's actually exactly what is happening in these cases :) The data you see on the console that looks malformed is just the string data in its raw, binary, form. This library is doing nothing to it.

If you're attempting to just print out all values to the console and don't want the output to get messed up then you're going to have to try to interpret the data in some way before printing it. One way would be to first check if the value has any non-printable characters (which could indicate a binary value of sorts) and if it does then parse it through bin2hex before dumping it to the console.