內核版本：2.6.34
雜談一：重復地址檢測
Linux協議棧中處理重復地址檢測報文的是arp_process()中的一段代碼， RFC2131是DHCP的草案，相應的sip==0是DHCP服務器用來檢測它所分發的地址是否重復的。
/* Special case: IPv4 duplicate address detection packet (RFC2131) */
if (sip == 0) {
if (arp->ar_op == htons(ARPOP_REQUEST) &&
inet_addr_type(net, tip) == RTN_LOCAL &&
!arp_ignore(in_dev, sip, tip))
arp_send(ARPOP_REPLY, ETH_P_ARP, sip, dev, tip, sha,
dev->dev_addr, sha);
goto out;
}
而根據RFC826中描述，正常的重復地址檢測報文特征是sip==tip
The gratuitous ARP packet is an ARP request with both sender's and the target's IP address fields containing the configured IP address.
A gratuitous ARP packet on an Ethernet is defined as
48.bit Destination Address = 0xffffffffffff (broadcast)
48.bit Source Address = Hardware adderss of interface
16.bit Frame type = 0x806 (ARP)
----------------------
16.bit Hardware type = 0x1 (Ethernet)
16.bit Protocol Type = 0x800 (IP)
8.bit Hardware Address size = 6
8.bit Protocol Address size = 4
16.bit Opcode = 1 (Request)
48.bit Sender Ethernet Address = Hardware address of interface
32.bit Sender IP Address = Configured IP address
48.bit Target Ethernet Address = Don't care
32.bit Target IP Address = Configured IP Address
問題：
linux協議棧除了對RFC2131規定的DHCP服務器使用的地址檢測格式進行響應，對RFC826中 規定的gratuitous arp報文不作處理，該報文會被協議棧直接丟棄掉。
實際情況是，在啟動linux網絡或配置新的IP時， Linux Host不會進行重復地址檢測，並且，對於其它主機發來的重復地址檢測報文也不會處理。
測試環境如下：
Linux Host的IP為 192.168.1.1，然後配置Windows Host的IP為192.168.1.1，Windows Host會發送gratuitous arp，但Linux Host並不會回應，默 許了兩個重復地址的存在。[誰能幫忙解釋下，感激]
雜談2：NUD狀態轉移的實際理解
根據NUD的狀態轉移，實際測試兩種 情況：NUD_INCOMPLETE和NUD_PROBE。
NUD_INCOMPLETE
Linux Host隨便telnet一個沒有使用的IP1，協議棧會為會IP1創建 一個鄰居表項，狀態由NUD_NONE遷移到NUD_INCOMPLETE，具體的協議棧流程在上篇ARP [http://blog.csdn.net/qy532846454/article/details/6806197]中分析的。
在Linux Host上telnet XX.XX.86.198，捕獲到 的發包狀況如下：
這三個報文是在進入NUD_INCOMPLETE狀態後，嘗試了3次ARP廣播(因為還未收到對方報文)，對應arp_tbl中的參數 mcast_probe=3次數，每次嘗試間的時間間隔近似1s，對應arp_tbl中的參數retrans_time = 1HZ。
NUD_PROBE
NUD_PROBE測 試復雜一點，先由一台Host1(IP2)向Linux Host發送arp request請求，協議棧會為IP2創建一個鄰居表項，狀態由NUD_NONE - > NUD_STALE，然後Linux Host會響應request，狀態由NUD_STALE -> NUD_DELAY -> NUD_PROBE，具體的協議棧流程在 上篇ARP[http://blog.csdn.net/qy532846454/article/details/6806197]中分析的。
由Host1構造假arp request(sip=未被 使用IP, tip=Linux Host IP)給Linux Host，捕獲到的發包狀況如下：
每一個包是Host1發出的request，每二個包是Linux Host的回復，後三個包是3次ARP單播嘗試，此時處於NUD_PROBE狀態要嘗 試對方是否存活，由於sip使用的是虛假址，因此沒有響應，在嘗試了最大次數3次，對應arp_tbl中的參數ucast_probe=3次數， 每次嘗試的間隔時間近似1s，對應arp_tbl中的參數retrans_time=1HZ。
對比下windows這方面的處理可以發現，兩者在這方 面的行為相差很大：比如windows的網絡協議棧會處理RFC826所規定的gratuitous arp報文；windows的arp嘗試只會進行一次。