当我使用函数encode
将八位字节转换为十六进制时,有些字符会在不该添加的情况下添加
示例:
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):
^{pr2}$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输出是“mangled”/转换的,要么是EasySNMP输出。在
不幸的是,包捕获并没有显示post原始版本中描述的交互,因此我们无法立即判断哪个管理器有问题。然而,根据我们看到的值进行推断是可能的。在
Python脚本的输出几乎是snmpwalk输出的超集:
网络SNMP:
Python脚本:
为什么又增加了一些字节呢?这听起来像是源数据的重新编码,对吧?在
我们可以观察到字节C2经常弹出。那是什么?这是字符的“扩展ASCII”(实际上没有这种东西,但在许多代码页中)。啊哈,红旗。为什么是红旗?因为this is commonly evidence of misinterpreted UTF-8。(我可以更详细地解释为什么是这样,但如果您愿意,我将让您单独研究Unicode编码。)
因此,使用an online tool或{a3},让我们将第二个字节流解码为UTF-8,然后看看我们得到了什么逻辑码位:
嘿,看起来很眼熟!(再次,我将匹配netsnmp输出的位加粗)U+00丢失(可能是因为that is a "null" byte much as in ASCII)并且结尾处仍然有一堆噪声(如果您感兴趣,它们呈现如下:“YN&;N”),但我们现在至少可以看到发生了什么:原来的字节流被重新编码为UTF-8字符串。事实上,Python 3's default encoding is UTF-8。在
像C6这样的字节完全消失的原因是它们不在ASCII范围内,所以在Unicode中映射“不干净”。ascicic6,结果是,is U+00C6, which is represented in UTF-8 by C3 86,所以现在我们也知道了未绑定字节的来源。在
因此,EasySNMP将walk结果视为一个字符串,而不是一个不透明的字节序列,结果Python弄乱了它。然后,当您编写
.encode("hex")
时,您得到了这个新的、伪造的UTF-8字符串的十六进制对表示。在这可能不应该发生。SNMP响应清楚地表示为“OctetString”,规范告诉我们"The ^{} 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字符串的方式,或者由前面描述的netsnmp compat模块来实现。在
但是,this chap has suggested a workaround你可以试试:
新的最后一个论点应该会关闭价值转换。但是,我不相信,因为默认情况下per the docs已经是{}。在
我想,除了尝试之外最好的办法是在相关的问题报告中增加权重,并向开发人员施压,让他们想出一个解决方案。对不起的。在
相关问题 更多 >
编程相关推荐