Tell me more ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.
up vote 4 down vote favorite

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.

share|improve this question
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 Sep 21 '12 at 9:51
thanks it says i need 10pts to be able to upload image, but for that reason i will try imgur from now on – Sara Sep 21 '12 at 9:59
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. – Oliver Salzburg♦ Sep 21 '12 at 10:14
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: tools.ietf.org/html/rfc826 – wmz Sep 21 '12 at 11:20
@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 Sep 21 '12 at 13:49

1 Answer

up vote 1 down vote accepted

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.

share|improve this answer
confusing answer – Sara Oct 23 '12 at 14:35
@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. – Ярослав Рахматуллин Oct 23 '12 at 18:22

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.