先來抽象介紹一下這個bug單.

       現象： 測試同事發現， 在區域網內， pc(w.x.y.10)和某裝置S(w.x.y.z.20)都 ping不通某ip(w.x.z.30)， 但裝置S(w.x.y.z.20)在檢測ip(w.x.y.30)的時候， 居然是通過的。

       我來翻譯一下： pc(w.x.y.10)和某裝置S(w.x.y.z.20)都 ping不通某ip(w.x.z.30)， 但裝置S(w.x.y.z.20)向ip(w.x.y.30)發arp請求， 居然收到了迴應，從現象和日誌中都可以看到， 是收到回覆了的。

       背景介紹一下： 該問題只在測試同事所在的區域網內復現， 在其他的區域網（比如我的）內不存在。

       當接到這個單的時候， 我感到非常納悶， 怎麼在所有其他地方都不存在問題， 就在你這裡存在問題呢？ 我初步感覺是測試同事那邊環境搭建的問題。 但感覺畢竟是感覺， 沒有確鑿的正確， 測試同事是不會放過的。 既然懷疑是她們的測試環境問題， 那就有必要拿出足夠的證據， 否則， 這個單是走不掉的。

       測試的同事白天要測試， 我要想用他們的環境， 那是不行的， 只能等她們晚上下班後， 我再借用環境。 可是， 借到環境後發現， 日誌列印不充分啊。 沒辦法， 繼續在程式碼中加日誌， 編譯，更新到裝置S中。 去定位問題又發現日誌不夠， 繼續加， 繼續編譯， 繼續更新。好吧， 這一路波折就不說了， 直接說定位過程。

       初步定位， 根據日誌， 我定位到的原因是：在裝置S(w.x.y.z.20)中，arp的sendto函式向ip(w.x.z.30)發起請求後， recv收到了回饋， 我很納悶， 怎麼在這個環境下， 居然能recv到東西呢？ 該ip(w.x.z.30)明明是不可達的啊。 追到sendto而recv這一層， 還是沒發現原因， 我開始感覺有點吃力了。

       不要氣餒， 肯定是有原因的。 我開始覺得， 日誌已經不足以分析了， 那還要怎樣？ 抓包？ 對了， 就是抓包。 我抓了個包， 發現居然還真有arp回覆， 包中的mac地址資訊寫的一清二楚， 是xx:xx:xx:xx:xx:xx。 於是， 接下來要看這個mac地址是哪個裝置的mac。

       接著， 我在測試同事的電腦上ping了一下w.x.y.30這個ip, 期望arp快取表中有xx:xx:xx:xx:xx:xx的資訊， 果然有， 再看看它對應的ip,  我大吃一驚， 是閘道器w.x.y.1, 而不是我們arp的物件w.x.y.30。 原來是閘道器w.x.y.1在回覆arp啊， 好神奇。

       我還是百思不得其解， 閘道器怎麼會自動去arp回覆ping不通的ip(w.x.y.30)呢？  上網查詢， 沒查到結果， 於是去問請教另外一個同事， 他經驗足。 他解答說： “她們那個區域網的閘道器就是這樣的（比較特殊）， 之前碰到過好幾次類似的情況。”  好吧， 現在是弄清了， 人證物證都在， 總算是有底氣和測試的MM溝通了

       最後結論： 本問題屬於非問題， 原因是blablablabla...

       感嘆一句， 要是早點抓包就好了， 以後要注意啊， 網路問題， 抓包抓包抓包。