LinuxQuestions.org - ARP replies appear with delay in tcpdump/Wireshark output

- Linux - Networking (https://www.linuxquestions.org/questions/linux-networking-3/)

- - ARP replies appear with delay in tcpdump/Wireshark output (https://www.linuxquestions.org/questions/linux-networking-3/arp-replies-appear-with-delay-in-tcpdump-wireshark-output-4175436598/)

ARP replies appear with delay in tcpdump/Wireshark output

If I send an ICMP "echo request" from 10.10.10.2 to 10.10.10.1, then according to tcpdump and Wireshark, 10.10.10.1 sends ICMP "echo reply" before ARP reply from 10.10.10.2 is received:

Code:

02:36:14.689050 00:1a:6b:6c:0c:cc > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 10.10.10.1 tell 10.10.10.2, length 46

02:36:14.689079 00:1d:09:f0:92:ab > 00:1a:6b:6c:0c:cc, ethertype ARP (0x0806), length 42: Reply 10.10.10.1 is-at 00:1d:09:f0:92:ab, length 28

02:36:14.689320 00:1a:6b:6c:0c:cc > 00:1d:09:f0:92:ab, ethertype IPv4 (0x0800), length 98: 10.10.10.2 > 10.10.10.1: ICMP echo request, id 8301, seq 1, length 64

02:36:14.689344 00:1d:09:f0:92:ab > 00:1a:6b:6c:0c:cc, ethertype IPv4 (0x0800), length 98: 10.10.10.1 > 10.10.10.2: ICMP echo reply, id 8301, seq 1, length 64

02:36:19.688639 00:1d:09:f0:92:ab > 00:1a:6b:6c:0c:cc, ethertype ARP (0x0806), length 42: Request who-has 10.10.10.2 tell 10.10.10.1, length 28

02:36:19.689815 00:1a:6b:6c:0c:cc > 00:1d:09:f0:92:ab, ethertype ARP (0x0806), length 60: Reply 10.10.10.2 is-at 00:1a:6b:6c:0c:cc, length 46

Wireshark output can be seen here.

Of course ARP traffic should appear before the ICMP "echo reply". Why tcpdump and Wireshark show ARP traffic with a delay? I use tcpdump version 4.1.1 and Wireshark 1.2.11. Both use libpcap 1.1.1. Any ideas what might cause such behavior?

I can't see why there are arps exactly 5 seconds later, it seems fair to say it must be related somehow, but it can reply because it would just use the mac on the incoming packet.

Ahh, it looks like it's the delay_first_probe_time setting.

Code:

/proc/sys/net/ipv4/neigh/DEV/delay_first_probe_time

Delay for the first time probe if the neighbor is reachable. (see gc_stale_time)



/proc/sys/net/ipv4/neigh/DEV/gc_stale_time

Determines how often to check for stale ARP entries. After an ARP entry is stale it will be resolved

again (which is useful when an IP address migrates to another machine). When ucast_solicit is greater

than 0 it first tries to send an ARP packet directly to the known host When that fails and

mcast_solicit is greater than 0, an ARP request is broadcast.