Why does a PING reply require an ARP request for the originating hosts MAC?

4

I have a scenario as depicted below.
Here two host machines are connected via a hub:

enter image description here

Ok, so host-1 wants to ping host-2 and i have setup wireshark on a 3rd host connected to the same hub. Now surprisingly for a single ping command to work, i see 6 packets, while there should be 4. Here it is what i see from wireshark:

enter image description here

Now what is beyond my understanding is that why the packet 5 & 6 are generated while isn't on ARP reply destination already knows the sender mac already.

Or is there something wrong with my understanding, please help.

Sara

Posted 2012-09-21T09:44:07.190

Reputation: 149

Just to note that even if you can't upload images directly, imgur would be a lot easier for folk to embed the images than imageshack - for one thing you can just post a direct link to the image – Journeyman Geek – 2012-09-21T09:51:41.060

thanks it says i need 10pts to be able to upload image, but for that reason i will try imgur from now on – Sara – 2012-09-21T09:59:36.770

Correlation doe not imply causation. Obviously, the echo reply is sent before the ARP request, so it's not required for the PING reply. Your operating system may just decide to give the old ARP table a little refresh after having sent the echo reply. Besides that, I would assume that you only rely on information you've determined yourself when implementing a TCP/IP stack. The risk of someone injecting information through specially crafted packets is too high. So you rather resolve MAC-to-IP yourself than use the data you got from previous packets. – Der Hochstapler – 2012-09-21T10:14:58.753

This looks as some form of gratuitous ARP. What's target mac in the 5th request? @OliverSalzburg Receiving node must honor information received in ARP packet and insert it into its own table, as specified in RFC 826: http://tools.ietf.org/html/rfc826

– wmz – 2012-09-21T11:20:27.517

@wmz, well in the 5th request the target mac is unknown (ff:ff:ff:ff:ff:ff) and ip is set for host-1. I have tested it many times but this is how it is, also if i block the last arp req/reply (as i am doing this through an openflow controller), the ping works however arp command yilds valid mac for host-2 inside host-1 machine, while shows it unknown mac for host/1 ip when run at host/2 machine. Because it was my understanding that only single arp req/reply should make both systems aware of each other, so i wanted to know if this is a bug or it really could happen as a normal behavior. Thanks – Sara – 2012-09-21T13:49:08.713

Answers

1

Original Answer

The first response comes from the hub interface, not host-1 interface. When sending things back you still need to know the mac of the interface with IP of host-1. Some switches do this automatically, others do not.

Improved answer:


              .-----------.
              | hub       |
              |           |
[host-1 i1]+--+hi1     hi2+--+[i2 host-2]
              |           |
              `-----------´

network interfaces: 
i1, i2, hi1, hi2

After sending something to host-1 from host-2 via an IP address in aplication layer, the initial response to host-2 (and all subsequent responses) will come from the hi2 interface, not the i1 interface in host-1.

In order to send anything to the already known IP of host-1, host-2 will still need to know where to send packets on the link layer. To do that, host-2 must request the MAC address of the interface baring the IP of host-1.

Some switches do this kind of translation automatically - they remember the mac-path backwards. Most hubs do not, hence the second request.

Ярослав Рахматуллин

Posted 2012-09-21T09:44:07.190

Reputation: 9 076

confusing answer – Sara – 2012-10-23T14:35:18.173

@Sara okay :\ I hope this is less confusing. The key to understanding this is that there are separate, independent communication layers and they know next to nothing about each other. – Ярослав Рахматуллин – 2012-10-23T18:22:09.787

Asked: 2012-09-21T09:44:07.190

Viewed: 9 011 times

Active: 2012-10-23T18:20:40.227