当我使用功能encode将OCTET转换为十六进制时，在不应该添加一些字符的情况下。
例：
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输出：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
码：
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输出：
iso.3.6.1.4.1.25355.3.2.6.4.2.5.1.7.1.1.1.144. OCTETSTR = c2acc284c3865fc295c3afc2b04e26c28b1cc385c3804a00c2ae59c293c2b04e26c28b4ec2ad使用了一些OID，但是输出与我预期的不同。这是使用easysnmp的正确方法吗？
封包捕获
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...
最佳答案
好的。我们可以告诉以下内容：
两位经理的要求相同
这两个请求的响应是相同的
这意味着要么Net-SNMP输出“被修改” /转换，要么EasySNMP输出被“修改”。
不幸的是，数据包捕获并没有显示该帖子原始版本中描述的交互，因此我们无法立即判断出哪个经理有问题。但是，可以根据我们看到的值进行推论。
Python脚本的输出几乎是snmpwalk输出的超集：
网络SNMP：
AC 84 C6 5F 95 EF B0 4E 26 8B 1C C5 C0 4A 00 AE
Python脚本：
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
那么为什么要增加额外的字节，又为什么要丢失一些字节呢？闻起来像是对源数据进行重新编码，对吗？
我们可以看到字节C2大量弹出。那是什么？这是字符Â的“扩展ASCII”（实际上没有这种东西，但是在许多代码页中）。啊哈，红旗。为什么会有危险信号？因为this is commonly evidence of misinterpreted UTF-8。 （我可以更详细地解释这是为什么，但是如果需要，我可以让您分别研究Unicode编码。）
因此，使用an online tool或two，让我们将第二个字节流解码为UTF-8，看看我们得到了哪些逻辑代码点：
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
嘿，看起来很熟悉！ （再次，我将与Net-SNMP输出匹配的位加粗了。）U + 00丢失（可能是因为that is a "null" byte much as in ASCII），最后仍然有很多噪音（如果您感兴趣，它们会像这个：“ Y”°N＆‹N”），但我们现在至少可以看到发生了什么：您的原始字节流已重新编码为UTF-8字符串。确实是Python 3's default encoding is UTF-8。
像C6这样的字节完全消失的原因是它们不在ASCII范围之内，因此在Unicode中“不干净”地映射。原来是ASCII C6，is U+00C6, which is represented in UTF-8 by C3 86，所以现在我们也知道未固定字节来自何处。
因此，EasySNMP将步行结果视为字符串而不是不透明的字节序列，因此Python对其进行了处理。然后，当您编写.encode("hex")时，就得到了这个伪造的UTF-8新字符串的十六进制对表示。
这可能应该不会发生。 SNMP响应明确表示为“ OctetString”，并且规范告诉我们"The OCTET STRING type represents arbitrary binary or textual data"。与您通信的代理程序的MIB（您似乎没有使用或至少没有提供）可能会提供进一步的编码信息；在没有该信息的情况下，无法确定如何显示OCTET STRING。例如，this Net-SNMP bug讨论了在适用时从字面上进行猜测。
无论如何，都很有趣，但是我们能做些什么呢？
EasySNMP文档相当薄，但是我们可以在源代码中稍作修改（并在此过程中发现EasySNMP is actually just a Python wrapper around Net-SNMP!），并在EasySNMP问题列表中找到someone's complained about this before。
再次，那么，我们该怎么办？
嗯，我不确定我们能做很多事情。当前，这是EasySNMP中的缺陷。事物是唯一的（通过EasySNMP本身，通过转换为Python字符串或通过前面描述的Net-SNMP兼容模块），即使它们不应该如此。
但是，您可以尝试this chap has suggested a workaround：
session = Session(
hostname='192.168.10.150',
community='public',
version=2,
use_sprint_value=False
)
这个新的最后论据应该关闭价值转换。但是，我不相信，因为per the docs默认情况下已经为
False。除了尝试尝试之外，我认为您最好的选择是增加对相关问题报告的重视，并向开发人员施加压力，要求他们提出解决方案。抱歉。