我正在使用snmpV3适配器并使用以下命令将V2陷阱传递给它。看起来类型u（即无符号）的范围高达（2 ^ 31）-1（即2147483647）。我原以为是（2 ^ 32） - 1（即4294967295）。
snmptrap -c public -v 2c clm-pun-009642 '' 1.3.6.1.4.1.20006.1.0.5 1.3.6.1.4.1.12345.1 u 2147483647
以上命令生成以下日志：
trace: ..\..\snmplib\snmp_api.c, 5293:
dumph_recv: Value
dumpx_recv: 42 04 7F FF FF FF
dumpv_recv: UInteger: 2147483647 (0x7FFFFFFF)
至于：
snmptrap -c public -v 2c clm-pun-009642 '' 1.3.6.1.4.1.20006.1.0.5 1.3.6.1.4.1.12345.1 u 2147483648
以上命令生成以下日志：
enter code heretrace: ..\..\snmplib\snmp_api.c, 5293:
dumph_recv: Value
dumpx_recv: 42 05 00 80 00 00 00
dumpv_recv: UInteger: -2147483648 (0x80000000)
参考： http://www.net-snmp.org/docs/man/snmptrap.html
我正在使用net-snmp v5.5。
这是正确的行为还是我错过了什么？
答案 0 :(得分：0)
多年来我发现了net-snmp的各种问题。这显然是一个。标准很清楚。 RFC 2578将Unsigned32定义如下：
- 无符号32位数量 - 与Gauge32 Unsigned32 :: =无法区分 [申请2] IMPLICIT INTEGER（0..4294967295）
如上所述，这与Gauge32完全相同，与SNMPv1（RFC 1155）中的Gauge相同：
Gauge :: = [申请2] IMPLICIT INTEGER（0..4294967295）
编码是正确的; SNMP中的所有整数都被编码为有符号，这意味着大于2 ^ 31-1的值必须以5个字节进行编码。因此，编码的正确翻译是：
42 Type: Gauge32 or Unsigned32
05 Length: 5 bytes
00 80 00 00 00 Value: 2^31
net-snmp错误地解码了该值。