Linux kernel Analysis

Kernel version: 2.6.34

Duplicate address detection

The Linux protocol stack handles duplicate address detection packets is a piece of code in Arp_process (), RFC2131 is a draft of DHCP, and the corresponding sip==0 is used by the DHCP server to detect whether the addresses it distributes are duplicates.

/* Special CASE:IPV4 Duplicate address detection packet (RFC2131)/ 
if (sip = 0) {
    if (Arp->ar_op = htons (A) rpop_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;
}

As described in RFC826, the normal duplicate address detection message is characterized by sip==tip

The gratuitous ARP packet is a ARP request with both sender ' s and the target's IP address fields containing the Configure D IP address.

A gratuitous ARP Packet on the 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

Problem:

Linux protocol Stack In addition to the RFC2131 specified DHCP server address detection format to respond to the RFC826 of the gratuitous ARP message is not processed, the message will be directly discarded by the protocol stack.

The reality is that the Linux host does not duplicate address detection when you start a Linux network or configure a new IP, and the duplicate address detection messages that are sent to other hosts are not processed.

The test environment is as follows:

Linux host IP is 192.168.1.1, and then configure Windows host IP for 192.168.1.1,windows host to send gratuitous ARP, but Linux host does not respond, the default The existence of two duplicate addresses was allowed. [Who can help explain, appreciate]

A practical understanding of 2:nud State Transfer

According to the state transfer of NUD, two kinds of conditions are actually tested: Nud_incomplete and Nud_probe.

Nud_incomplete

Linux host casually telnet a unused IP1, the protocol stack will IP1 create a neighbor table entries, the state from Nud_none to Nud_incomplete, the specific protocol stack process in the ARP [http://blog.csdn.net /QY532846454/ARTICLE/DETAILS/6806197] in the analysis.

Telnet XX on the Linux host. xx.86.198, the captured contract status is as follows:

These three messages after entering the Nud_incomplete state, tried 3 ARP broadcast (because has not received the other message), corresponding arp_tbl in the number of parameters mcast_probe=3, each attempt between the time interval approximately 1s, corresponding arp_ The parameter Retrans_time = 1HZ in tbl.

Nud_probe

The Nud_probe test is a bit more complicated by sending ARP request requests from a Host1 (IP2) to the Linux host, which creates a neighbor table entry for IP2, state by Nud_none-> Nud_stale, and then Linux Host will respond to request, state by Nud_stale-> Nud_delay-> Nud_probe, the specific protocol stack flow in the last chapter arp[http://blog.csdn.net/qy532846454/ ARTICLE/DETAILS/6806197] in the analysis.

The Host1 constructs the fake ARP request (sip= is not used IP, tip=linux host IP) to the Linux host, captures the contract status as follows:

Each package is a request issued by HOST1, every two packets are the Linux host reply, the latter three packets are 3 ARP unicast attempts, at this time in the Nud_probe state to try whether the other side is alive, because the SIP is using a false address, so there is no response, the maximum number of attempts to try 3 times, corresponding to the ucast_probe=3 number of parameters in Arp_tbl, the interval of each attempt is approximately 1s, corresponding to the parameter retrans_time=1hz in ARP_TBL.

Comparing windows this aspect of the processing can be found that the behavior of the two in this area is very different: for example, the Windows network protocol stack will handle the RFC826 of the gratuitous ARP message; Windows ARP attempt only occurs once.