如何檢測另一個主機是否使用與當前主機相同的MAC地址（例如，因爲其他主機是欺騙？檢測具有相同MAC地址的另一個主機
我在嵌入式環境中工作，所以找一個協議層次的答案，而不是「用這樣或那樣的工具」。
編輯：RARP確實不是解決了這個問題。爲了讓RARP得到任何答覆，必須在支持RARP的網段上至少有一臺主機。由於RARP已經過時，現代操作系統不支持它。此外，所有RARP都可以告訴你自己的IP地址 - 如果在具有相同MAC的網段上有另一個主機，則該響應不會有任何不同，除非該主機本身使用了不同的IP地址。在單一網段使用相同的MAC地址
這個問題太放人了！在幾次錯誤的開始之後，我開始思考問題的基本組成部分，並向RFC尋求建議。 我還沒有找到一個明確的答案，但這裏是我的思維過程，希望它有助於：
原來的問題詢問如何檢測其他設備與您的MAC地址。假設你在一個IP網絡上，完成這個需要什麼？
的被動方法是簡單地聽交通和尋找，你沒有發射，但有你的MAC地址的任何數據包。這可能會或可能不會發生，所以雖然它可以告訴你明確是否存在重複，它不能告訴你明確說沒有。
不限活性方法要求發送一個數據包力冒名頂替者作出反應。這立即消除了任何依賴於可選協議的方法。
如果有其他設備欺騙你，它必須（顧名思義），使報文帶着您 MAC地址作爲目的做出迴應。否則，它窺探但不欺騙。
該解決方案應該是獨立的IP地址，並且僅涉及MAC地址。
所以答案，看來，將是要麼發送廣播（以太網）數據包，或與您的MAC地址作爲其目標，這需要一個響應包。 Monkeywrench是一個IP地址通常涉及，你不知道它。
什麼樣的協議適合這種描述？
簡單的答案：
不那麼容易回答：
這是獨立的IP的協議：一方不使用IP層，或一個允許廣播。沒有人想到。
發送任何數據包通常會生成您的響應，阻止您的響應並查找來自其他設備的響應。使用你的IP地址作爲目的地似乎是明智的，但我並不相信這一點。不幸的是，細節（以及答案）留給了OP的練習......但是我希望討論是有幫助的。
我懷疑最終的解決方案將涉及技術的組合，因爲沒有任何一種方法似乎可以保證可靠的決心。
一些信息，請http://en.wikipedia.org/wiki/ARP_spoofing#Defenses
如果一切都失敗了，你可能會喜歡這樣的：http://www.rfc-editor.org/rfc/rfc2321.txt
請張貼跟進你的解決方案，因爲我敢肯定，這將是有益的給他人。祝你好運！
兩個主機可能會使開關發瘋，你很可能由具有極不可靠的網絡連接（如開關將發出屬於您的主機的數據包的某些部分檢測出來第二個，取決於你們哪一方向他們的方向發送了最後一個數據包）。
您可以發送一個ARP請求在子網中的每個可能的IP。 當然，ARP請求的源地址必須是ff：ff：ff：ff：ff：ff，否則你可能看不到響應。
我用bittwiste僞造了一個這樣的數據包，並用PReplay重播了它，網絡上的所有主機都收到了響應。 （我不知道如果這些僞造的ARP數據包是合法的或不...某些操作系統可能會忽略它們）
這裏是僞造的包看起來像： 
這裏的答覆是什麼樣子： 
如果你看的答覆，並看到包一個您的MAC地址（在紅色矩形），比別人有相同的MAC地址做什麼...
Unfortuantely我不能」完全檢驗理論，因爲沒有一個m y（Windows）機器關心我試圖設置網卡的MAC地址...
這是非常晚，並且是無法回答的，但我想跟進到底我做了什麼以防其他人感興趣。
我正在使用一些非常奇怪的嵌入式硬件，它沒有在製造時分配的MAC地址。這意味着我們需要用軟件分配一個。
顯而易見的解決方案是讓用戶選擇一個他們知道在他們的網絡上可用的MAC地址，最好是從本地管理的範圍，這就是我所做的。但是，我想選擇一個合理安全的默認值，並且在發生衝突時嘗試警告用戶。
最後，我決定在本地管理的範圍內選擇隨機默認設置，通過製作一些具有中等熵的硬件讀數進行選擇。我故意排除了這個範圍的開始和結束，因爲我們假定這些範圍可能是手動選擇的。有可能在任何給定的網絡上只有這些設備中的一個，並且當然少於20個，所以衝突的可能性非常低，儘管不會像可預測的隨機數那樣低。
鑑於出現問題的可能性很小，並且儘管上面有出色的答案，我決定免除衝突檢測，並提醒用戶注意MAC衝突問題。
如果我確實決定實施衝突檢測，那麼考慮到我控制整個網絡堆棧，我可能會查找過多的未知或丟失的數據包，然後觸發MAC地址更改或在發生此情況時發出警告。
希望這可以幫助別人 - 但可能不會！
感謝您的出色反應。 爲了我的目的，可以依靠IP--我不希望支持非IP網絡:)。 我一定會跟進。 – 2008-11-10 14:30:56