SNMP4J的一點缺陷

 最近在使用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地址轉發表的命令行如下：

 

snmpwalk -c public -v 2c 192.168.1.1 .1.3.6.1.2.1.17.4.3

在對上述的那些交換機通過上述命令行獲取其mac地址轉發表的時候，會返回以下結果：

 

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

第23行中可以看到錯誤提示，OID not increasing的錯誤，原來某些設備對SNMP支持的原因，會導致返回結果的OID不是遞增的，其實不應該說是遞增，只能說是增大。查看snmpwalk的man手冊後，找到了解決方法：

 

-Cc
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的源代碼，給出一個答案，也希望知道的朋友能夠提示一下。