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

?

轉載于:https://blog.51cto.com/njulinq/289265

總結

以上是生活随笔為你收集整理的SNMP4J的一点缺陷的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。