DEVHIDE
Login Or Sign up

EasySNMP: Different output converting OCTETSTR to Hex

2.5k Views Asked by At

When I use the function encode to convert OCTET to Hex, some characters are add when it shouldn't.

Example:

Linux: snmpwalk -t 5 -v2c -c public 192.168.10.150 iso.3.6.1.4.1.25355.3.2.6.4.2.5.1.7.1.1.1

SNMPWALK output: iso.3.6.1.4.1.25355.3.2.6.4.2.5.1.7.1.1.1.144 = Hex-STRING: AC 84 C6 5F 95 EF B0 4E 26 8B 1C C5 C0 4A 00 AE

Code:

session = Session(hostname='192.168.10.150', community='public', version=2)
description = session.walk('iso.3.6.1.4.1.25355.3.2.6.4.2.5.1.7.1.1.1')

for item in description:
    print '{oid}.{oid_index} {snmp_type} = {value}'.format(
         oid=item.oid,
         oid_index=item.oid_index,
         snmp_type=item.snmp_type,
         value=item.value.encode("hex"))

EasySNMP output: iso.3.6.1.4.1.25355.3.2.6.4.2.5.1.7.1.1.1.144. OCTETSTR = c2acc284c3865fc295c3afc2b04e26c28b1cc385c3804a00c2ae59c293c2b04e26c28b4ec2ad

Some OIDs are used, but the output is different from what I expected. Is it the correct the way to use easysnmp?

Packet Capture

SNMPWalk (Linux):

    192.168.10.214  192.168.10.150  get-next-request 1.3.6.1.4.1.25355.3.2.6.4.2.5.1.7.1.1.1 Value(NULL)
Simple Network Management Protocol
    version: v2c (1)
    community: public
    data: get-next-request (1)
        get-next-request
            request-id: 686772965
            error-status: noError (0)
            error-index: 0
            variable-bindings: 1 item
                1.3.6.1.4.1.25355.3.2.6.4.2.5.1.7.1.1.1: Value (Null)
                    Object Name: 1.3.6.1.4.1.25355.3.2.6.4.2.5.1.7.1.1.1 (iso.3.6.1.4.1.25355.3.2.6.4.2.5.1.7.1.1.1)
                    Value (Null)

    192.168.10.150  192.168.10.214  get-response 1.3.6.1.4.1.25355.3.2.6.4.2.5.1.7.1.1.1.51 
Value(00:02:18:a6:f7:65:88:f5:18:a6:f7:65:18:a6:f7:65:88:f5:b0:4e:26:8a:e3:cb:50:c7:bf:f2:db:95:b0:4e:26:ed:8d:c5:98:de:d0:76:e3:01:00:02:98:de:d0:76)
Simple Network Management Protocol
    version: v2c (1)
    community: public
    data: get-response (2)
        get-response
            request-id: 686772965
            error-status: noError (0)
            error-index: 0
            variable-bindings: 1 item
                1.3.6.1.4.1.25355.3.2.6.4.2.5.1.7.1.1.1.5: 000218a6f76588f518a6f76518a6f76588f5b04e268ae3cb...
                    Object Name: 1.3.6.1.4.1.25355.3.2.6.4.2.5.1.7.1.1.1.5 (iso.3.6.1.4.1.25355.3.2.6.4.2.5.1.7.1.1.1.5)
                    Value (OctetString): 000218a6f76588f518a6f76518a6f76588f5b04e268ae3cb...


    192.168.10.214  192.168.10.150  get-next-request 1.3.6.1.4.1.25355.3.2.6.4.2.5.1.7.1.1.1.5 Value(NULL)
Simple Network Management Protocol
    version: v2c (1)
    community: public
    data: get-next-request (1)
        get-next-request
            request-id: 686772966
            error-status: noError (0)
            error-index: 0
            variable-bindings: 1 item
                1.3.6.1.4.1.25355.3.2.6.4.2.5.1.7.1.1.1.5: Value (Null)
                    Object Name: 1.3.6.1.4.1.25355.3.2.6.4.2.5.1.7.1.1.1.5 (iso.3.6.1.4.1.25355.3.2.6.4.2.5.1.7.1.1.1.5)
                    Value (Null)


    192.168.10.150  192.168.10.214  get-response 1.3.6.1.4.1.25355.3.2.6.4.2.5.1.7.1.1.2.48 Value(70:4f:57:4d:cc:cf:b0:4e:26:8b:45:11:ac:84:c6:1d:0e:c5:70:4f:57:3a:dd:5b:70:4f:57:4c:92:8f:b0:4e:26:8a:ef:99)
Simple Network Management Protocol
    version: v2c (1)
    community: public
    data: get-response (2)
        get-response
            request-id: 686772966
            error-status: noError (0)
            error-index: 0
            variable-bindings: 1 item
                1.3.6.1.4.1.25355.3.2.6.4.2.5.1.7.1.1.2.48: 704f574dcccfb04e268b4511ac84c61d0ec5704f573add5b...
                    Object Name: 1.3.6.1.4.1.25355.3.2.6.4.2.5.1.7.1.1.2.48 (iso.3.6.1.4.1.25355.3.2.6.4.2.5.1.7.1.1.2.48)
                    Value (OctetString): 704f574dcccfb04e268b4511ac84c61d0ec5704f573add5b...

EasySNMP:

    192.168.10.214  192.168.10.150  get-next-request 1.3.6.1.4.1.25355.3.2.6.4.2.5.1.7.1.1.1 Value(NULL)
Simple Network Management Protocol
    version: v2c (1)
    community: public
    data: get-next-request (1)
        get-next-request
            request-id: 1767019562
            error-status: noError (0)
            error-index: 0
            variable-bindings: 1 item
                1.3.6.1.4.1.25355.3.2.6.4.2.5.1.7.1.1.1: Value (Null)
                    Object Name: 1.3.6.1.4.1.25355.3.2.6.4.2.5.1.7.1.1.1 (iso.3.6.1.4.1.25355.3.2.6.4.2.5.1.7.1.1.1)
                    Value (Null)


    192.168.10.150  192.168.10.214  get-response 1.3.6.1.4.1.25355.3.2.6.4.2.5.1.7.1.1.1.5 Value(00:02:18:a6:f7:65:88:f5:18:a6:f7:65:18:a6:f7:65:88:f5:b0:4e:26:8a:e3:cb:50:c7:bf:f2:db:95:b0:4e:26:ed:8d:c5:98:de:d0:76:e3:01:00:02:98:de:d0:76)
Simple Network Management Protocol
    version: v2c (1)
    community: public
    data: get-response (2)
        get-response
            request-id: 1767019562
            error-status: noError (0)
            error-index: 0
            variable-bindings: 1 item
                1.3.6.1.4.1.25355.3.2.6.4.2.5.1.7.1.1.1.5: 000218a6f76588f518a6f76518a6f76588f5b04e268ae3cb...
                    Object Name: 1.3.6.1.4.1.25355.3.2.6.4.2.5.1.7.1.1.1.5 (iso.3.6.1.4.1.25355.3.2.6.4.2.5.1.7.1.1.1.5)
                    Value (OctetString): 000218a6f76588f518a6f76518a6f76588f5b04e268ae3cb...



    192.168.10.214  192.168.10.150  get-next-request 1.3.6.1.4.1.25355.3.2.6.4.2.5.1.7.1.1.1.5 Value(NULL)
Simple Network Management Protocol
    version: v2c (1)
    community: public
    data: get-next-request (1)
        get-next-request
            request-id: 1767019563
            error-status: noError (0)
            error-index: 0
            variable-bindings: 1 item
                1.3.6.1.4.1.25355.3.2.6.4.2.5.1.7.1.1.1.5: Value (Null)
                    Object Name: 1.3.6.1.4.1.25355.3.2.6.4.2.5.1.7.1.1.1.5 (iso.3.6.1.4.1.25355.3.2.6.4.2.5.1.7.1.1.1.5)
                    Value (Null)


    192.168.10.150  192.168.10.214  get-response 1.3.6.1.4.1.25355.3.2.6.4.2.5.1.7.1.1.2.48 VALUE(70:4f:57:4d:cc:cf:b0:4e:26:8b:45:11:ac:84:c6:1d:0e:c5:70:4f:57:3a:dd:5b:70:4f:57:4c:92:8f:b0:4e:26:8a:ef:99)
Simple Network Management Protocol
    version: v2c (1)
    community: public
    data: get-response (2)
        get-response
            request-id: 1767019563
            error-status: noError (0)
            error-index: 0
            variable-bindings: 1 item
                1.3.6.1.4.1.25355.3.2.6.4.2.5.1.7.1.1.2.48: 704f574dcccfb04e268b4511ac84c61d0ec5704f573add5b...
                    Object Name: 1.3.6.1.4.1.25355.3.2.6.4.2.5.1.7.1.1.2.48 (iso.3.6.1.4.1.25355.3.2.6.4.2.5.1.7.1.1.2.48)
                    Value (OctetString): 704f574dcccfb04e268b4511ac84c61d0ec5704f573add5b...
python hex snmp octetstring
Original Q&A
3

There are 3 best solutions below

4
On BEST ANSWER

Okay. We can tell the following:

  • The requests are identical from both managers
  • The responses to both requests are identical

This means that either the Net-SNMP output is "mangled"/transformed, or the EasySNMP output is.

Unfortunately the packet captures don't show the interactions that were described in the original version of the post, so we cannot immediately tell which manager is at fault. However, it is possible to make a deduction based on the values that we see.

Your Python script's output is almost a superset of the snmpwalk output:

  • Net-SNMP:

    • AC 84 C6 5F 95 EF B0 4E 26 8B 1C C5 C0 4A 00 AE

  • Python script:

    • C2 AC C2 84 C3 86 5F C2 95 C3 AF C2 B0 4E 26 C2 8B 1C C3 85 C3 80 4A 00 C2 AE 59 C2 93 C2 B0 4E 26 C2 8B 4E C2 AD

So why have additional bytes been added, and why have some bytes been lost? This smells like a re-encoding of the source data, right?

We can observe that byte C2 pops up a lot. What's that? It's the "extended ASCII" (there's actually no such thing, but in many codepages) for the character Â. Aha, red flag. Why's it a red flag? Because this is commonly evidence of misinterpreted UTF-8. (I could explain in more detail why this is, but I'll let you research Unicode encodings separately if you desire.)

So, using an online tool or two, let's decode that second byte stream as UTF-8 and see what logical codepoints we get:

U+AC U+84 U+C6 U+5F U+95 U+EF U+B0 U+4E U+26 U+8B U+1C U+C5 U+C0 U+4A U+AE U+59 U+93 U+B0 U+4E U+26 U+8B U+4E U+AD

Hey, that looks familiar! (Again, I've bolded the bits that match the Net-SNMP output.) U+00 is missing (presumably because that is a "null" byte much as in ASCII) and there's still a bunch of noise at the end (if you're interested, they render like this: "Y°N&N­"), but we can now at least see what's going on: your original byte stream has been re-encoded as a UTF-8 string. Indeed, Python 3's default encoding is UTF-8.

The reason that bytes like C6 disappeared entirely is that they fall outside of the ASCII range, so map "uncleanly" in Unicode. ASCII C6, it turns out, is U+00C6, which is represented in UTF-8 by C3 86, so now we know where the unbolded bytes come from, too.

So, EasySNMP is treating your walk result as a string rather than as an opaque sequence of bytes, and as a result Python has mangled it. Then, when you wrote .encode("hex"), you got the hex-pair representation of this new, falsified UTF-8 string.

This should probably not be happening. The SNMP response is clearly indicated as an "OctetString", and the spec tells us that "The OCTET STRING type represents arbitrary binary or textual data". The MIB (which you do not appear to be using, or at least have not provided) for the agent with which you are communicating may provide further encoding information; in the absence of that information, there's no way to know for sure how an OCTET STRING should be displayed. For example, this Net-SNMP bug discusses literally making a guess when applicable.

Anyway, all very interesting, but what can we do about it?

The EasySNMP docs are fairly thin, but we can poke around in the source code a bit (and, in the process, discover that EasySNMP is actually just a Python wrapper around Net-SNMP!) and on the EasySNMP issues list, where it turns out someone's complained about this before.

Again, then, what can we do about it?

Um, I'm not sure that there's much we can do about it. This is currently a flaw in EasySNMP. Things are Unicodised (either by EasySNMP itself, by way of conversion to Python strings, or by the Net-SNMP compat module described earlier) even when they should not be.

However, this chap has suggested a workaround that you could try:

session = Session(
   hostname='192.168.10.150',
   community='public',
   version=2,
   use_sprint_value=False
)

That new final argument ought to turn off value transformation. However, I'm not convinced, because per the docs it's already False by default.

Beyond trying it anyway, I think your best bet is to add your weight to the relevant issue report(s) and pressure the developer to come up with a fix. Sorry.

0
On

To get the right hex value, I'm using this.

     def toRaw(s):
       x = [ord(i) for i in list(s)]
       return bytearray(x)
     
     print(toRaw(item.value).hex().upper())
0
On

I believe you're having the same issue that I have. I've talked about it on Github recently as well. Compat.py within the library is encoding the data as latin-1 instead of utf-8.

Regardless, based on your original code example the following should work:

session = Session(hostname='192.168.10.150', community='public', version=2)
description = session.walk('iso.3.6.1.4.1.25355.3.2.6.4.2.5.1.7.1.1.1')

for item in description:
    print '{oid}.{oid_index} {snmp_type} = {value}'.format(
         oid=item.oid,
         oid_index=item.oid_index,
         snmp_type=item.snmp_type,
         value=item.value.encode("latin-1").hex())

This will give you the hex as a continuous string. If you'd rather it as a bytes object just leave off the '.hex()' in value.

You could also do some comparisons if you wanted to be sure if you know the hex with something like:

from easysnmp import snmp_get

OID = iso.0.8802.1.1.2.1.4.1.1.7.2520.9.1
foo = snmp_get(OID, hostname='192.0.2.1', community='public', version=2).value.encode('latin-1')
foo == bytes.fromhex("312f3300")

In that example we're assuming the OID is returning the 31 2F 33 00 hex value for comparison.

Related Questions in PYTHON

Related Questions in HEX

Related Questions in SNMP

Related Questions in OCTETSTRING

Trending Questions

Popular # Hahtags

javascript python java c# php android html jquery c++ css ios sql mysql r reactjs node.js arrays c asp.net json python-3.x ruby-on-rails .net sql-server swift django angular objective-c pandas excel

Popular Questions

Copyright © 2021 Jogjafile Inc.