最近在使用SNMP4J的过程中发现一个缺陷，不知道应不应该算是个bug，但我想终究算是一个不完善的地方。

问题描述如下：

在通过SNMP4J去获取某些交换机上的MAC地址转发表(dot1dTpFdbTable, OID为1.3.6.1.2.1.17.4.3）时，发现结果不全，这里说其不全是与net-snmp提供的snmpwalk取的结果相比较而言的，snmpwalk也提供了相同的功能可以获取snmp table。不过直接用snmpwalk取的时候实际上也碰到了一个问题，例如假设交换机IP地址为192.168.1.1，支持SNMPv2c，且其团体字符串为public，则取MAC地址转发表的命令行如下：

1. snmpwalk -c public -v 2c 192.168.1.1 .1.3.6.1.2.1.17.4.3

在对上述的那些交换机通过上述命令行获取其mac地址转发表的时候，会返回以下结果：

1. SNMPv2-SMI::mib-2.17.4.3.1.1.0.3.15.1.205.11 = Hex-STRING: 00 03 0F 01 CD 0B
2. SNMPv2-SMI::mib-2.17.4.3.1.1.0.3.15.13.238.195 = Hex-STRING: 00 03 0F 0D EE C3
3. SNMPv2-SMI::mib-2.17.4.3.1.1.0.3.15.13.238.219 = Hex-STRING: 00 03 0F 0D EE DB
4. SNMPv2-SMI::mib-2.17.4.3.1.1.0.3.15.13.239.119 = Hex-STRING: 00 03 0F 0D EF 77
5. SNMPv2-SMI::mib-2.17.4.3.1.1.0.3.15.13.239.131 = Hex-STRING: 00 03 0F 0D EF 83
6. SNMPv2-SMI::mib-2.17.4.3.1.1.0.3.15.13.239.191 = Hex-STRING: 00 03 0F 0D EF BF
7. SNMPv2-SMI::mib-2.17.4.3.1.1.0.3.15.13.239.231 = Hex-STRING: 00 03 0F 0D EF E7
8. SNMPv2-SMI::mib-2.17.4.3.1.1.0.3.15.17.254.48 = Hex-STRING: 00 03 0F 11 FE 30
9. SNMPv2-SMI::mib-2.17.4.3.1.1.0.3.15.18.8.6 = Hex-STRING: 00 03 0F 12 08 06
10. SNMPv2-SMI::mib-2.17.4.3.1.1.0.3.15.18.8.124 = Hex-STRING: 00 03 0F 12 08 7C
11. SNMPv2-SMI::mib-2.17.4.3.1.1.0.3.15.18.8.178 = Hex-STRING: 00 03 0F 12 08 B2
12. SNMPv2-SMI::mib-2.17.4.3.1.1.0.3.15.18.8.186 = Hex-STRING: 00 03 0F 12 08 BA
13. SNMPv2-SMI::mib-2.17.4.3.1.1.0.3.15.18.8.190 = Hex-STRING: 00 03 0F 12 08 BE
14. SNMPv2-SMI::mib-2.17.4.3.1.1.0.3.15.18.8.210 = Hex-STRING: 00 03 0F 12 08 D2
15. SNMPv2-SMI::mib-2.17.4.3.1.1.0.3.15.18.9.234 = Hex-STRING: 00 03 0F 12 09 EA
16. SNMPv2-SMI::mib-2.17.4.3.1.1.0.3.15.19.38.92 = Hex-STRING: 00 03 0F 13 26 5C
17. SNMPv2-SMI::mib-2.17.4.3.1.1.0.3.15.19.46.100 = Hex-STRING: 00 03 0F 13 2E 64
18. SNMPv2-SMI::mib-2.17.4.3.1.1.0.3.15.19.46.154 = Hex-STRING: 00 03 0F 13 2E 9A
19. SNMPv2-SMI::mib-2.17.4.3.1.1.0.3.15.19.65.82 = Hex-STRING: 00 03 0F 13 41 52
20. SNMPv2-SMI::mib-2.17.4.3.1.1.0.3.15.19.65.106 = Hex-STRING: 00 03 0F 13 41 6A
21. SNMPv2-SMI::mib-2.17.4.3.1.1.0.3.15.19.66.158 = Hex-STRING: 00 03 0F 13 42 9E
22. SNMPv2-SMI::mib-2.17.4.3.1.1.0.3.15.19.66.158 = Hex-STRING: 00 03 0F 13 42 9E
23. Error: OID not increasing: SNMPv2-SMI::mib-2.17.4.3.1.1.0.3.15.19.66.158
24. >= SNMPv2-SMI::mib-2.17.4.3.1.1.0.3.15.19.66.158

第23行中可以看到错误提示，OID not increasing的错误，原来某些设备对SNMP支持的原因，会导致返回结果的OID不是递增的，其实不应该说是递增，只能说是增大。查看snmpwalk的man手册后，找到了解决方法：

1. -Cc
2. Do not check whether the returned OIDs are increasing. Some agents (LaserJets are an example) return OIDs out of order, but can complete the walk anyway. Other agents return OIDs that are out of order and can cause snmpwalk to loop indefinitely. By default, snmpwalk tries to detect this behavior and warns you when it hits an agent acting illegally. Use -Cc to turn off this check.

即在snmpwalk中增加-Cc选项后即可解决该问题，因为加上该选项后，snmpwalk将不再检查OID的升序问题，但有可能产生一个新问题就是导致snmpwalk陷入死循环。死循环的问题这里暂且不表。

不知道SNMP4J里面有没有对这个问题的解决方法，即类似snmpwalk中的-Cc选项的功能。后面有时间会再看看SNMP4J的源代码，给出一个答案，也希望知道的朋友能够提示一下。