如何確定遠端主機的snmp服務是否開啟

    最近幾天在做一件事情：確定遠端主機是否開啟了snmp服務。最初覺得這並不是一件很難的事情，但是世界上大多數的事情都會事與願違，隨著慢慢深入，這個問題開始逐漸展露她猙獰的面容。（呵呵，最近恐怖小說看的多了點）。

  
一開始，我覺得這個問題是一個普遍的問題，進一步理解，這個問題是這樣的：通過標準snmp我向遠端主機發出詢問資訊，如mib為sysDesc節點，如
果該主機沒有安裝SNMP服務，那麼我得到了一個timeout的response；如果我使用了一個錯誤的community那麼我也會得到一個
timeout的response，我希望能夠區分這兩種情況。

   
開始我覺得第三方對SNMP進行封裝的JAR可能已經解決了這個問題如snmp4j這個很受好評的開源項目。但是在API中並沒有找到適用的。再次尋找失
敗後遂給snmp4j的mail
list發信詢問這個問題，很快得到了回覆：cannot distinguish them (with any SNMP
entity), because that is behavior is the desired
one，為什麼呢？這一切都是為什麼呢？忽然醒悟該死的SNMP使用的是UDP協議（161,162）。而該死的UDP協議是個極其不負責任但是卻很有效
率的協議，簡單來說就是你只管發，UDP連接埠只管收，至於收到沒，還是收到的是個錯誤的包，它都不會告訴你，也不保證你發出去的一定能收到（相對於TCP
協議，很負責人的如三向交握）。這就是在你用了錯誤的community後不能奢望SNMP能告訴你，你只會得到一個timeout。

  
OK，這條路失敗了，但是我知道了根本原因是SNMP使用了UDP協議，那就從UDP連接埠探測入手。google一場，我檫！UDP連接埠探測可是個麻煩的事情，老外有篇文章：The
trouble with UDP port scanning,
講的很透徹了。UDP連接埠探測所依賴的基本原理是：如果向一個未被啟用的UDP連接埠發送包，該連接埠所在系統會回傳一個連接埠不可達ICMP報文，但是
1.這個ICMP報文並不是強制發送的，某些系統不會發送。2.這個報文可能被該主機的防火牆沒收。另外還有若干因素，總之，UDP連接埠探測有很大的不確定性，抓瞎啊！

   
至今，這個問題未果，另NMAP這個工具很厲害！
   
本文僅記錄這個未完成的問題，待有結果了再行續寫， 晚了，睡覺......