What happens if a host on the network receives an IP packet with a MAC source address that differs from the MAC address in the local ARP table for that source IP.

The ARP table entry for that IP was and will be filled via an valid ARP response.

Apparently a linux host won't just send an reply packet in such an scenario (ICMP echo response or TCP SYN/ACK ...etc).

I thought the receiving host just takes the source IP and and tries to find the corresponding MAC address in its local table.


First, thanks a lot for the answers so far, but they're only about ARP packet and table handling. Thats not answering my question, so i think i have to clearify the scenario:

enter image description here

If host Hb sends a ping request to (host Ha), Ha receives an ICMP packet with source IP and the source MAC address is the MAC address of the router. But the ARP table of host Ha has an entry: -> Hb MAC address. Thus the MAC addresses differ!

Now I have noticed that host Ha just does not send a reply packet (no packet is leaving the interface). The question is now for what reasons host Ha behaves this way.

  • Unfortunately, questions about hosts/servers are off-topic here. You could try to ask this question on Server Fault for a business network. – Ron Maupin Jul 19 '19 at 20:32
  • But actually i think my question is about a lab scenario and protocol theory. So maybe this is the right place for it? – fitcfitcfatc Jul 20 '19 at 11:19
  • 1. The host generates a ICMP echo reply. 2. The host looks in its routing table to determine which interface to use to send the response , based on the IP address. 3. If the routing table shows a next-hop, the host sends the packet to the next-hop gateway's MAC address. 4. If the destination network is directly connected, the host looks in its ARP table to find the MAC address and send the Ethernet frame to that address. If there is no ARP entry , the host generates an ARP request first. – Ron Trunk Jul 20 '19 at 13:24
  • I've already mentioned, there was no reply packet leaving the interface in my scenario. I started this question to get an answer why the host behaves like this. if somebody thinks the host should not act like this, then i also would like to know. – fitcfitcfatc Jul 20 '19 at 19:06
  • You question is very, very different now. That is bad form here. You should have really asked a different question in the first place. Your original question did not involve a router, separate network, and multiple interfaces on a host. Each interface maintains its own ARP table, not a single ARP table for the whole device, and packets are routed individually, regardless of what has come before. – Ron Maupin Jul 20 '19 at 20:07

ARP is a separate process, just like IP is a separate process. The frames will have the Ether Type field that tells the Data-Link (ethernet, Wi-Fi, etc.) protocol to which process it should send the frame payload.

Only frames with the Ether Type set to 0x0806 send the frame payload to ARP, which may update the ARP table. If the Ether Type is 0x0800, the frame payload is sent to the IPv4 process. If the Ether Type is 0x86DD, the frame payload is sent to the IPv6 process. Etc.

Received frames not having the Ether Type field set to 0x0806 do not update the ARP table. This is by design, and you can read about it in RFC 826, An Ethernet Address Resolution Protocol, where it describes how ARP works. In fact, not everything sent to ARP updates the ARP table. ARP replies certainly do, but other things received by ARP will only update the ARP table if an entry already exists for that IPv4 address:

?Do I have the hardware type in ar$hrd?
Yes: (almost definitely)
  [optionally check the hardware length ar$hln]
  ?Do I speak the protocol in ar$pro?
    [optionally check the protocol length ar$pln]
    Merge_flag := false
    If the pair <protocol type, sender protocol address> is
        already in my translation table, update the sender
        hardware address field of the entry with the new
        information in the packet and set Merge_flag to true.
    ?Am I the target protocol address?
      If Merge_flag is false, add the triplet <protocol type,
          sender protocol address, sender hardware address> to
          the translation table.
      ?Is the opcode ares_op$REQUEST?  (NOW look at the opcode!!)
        Swap hardware and protocol fields, putting the local
            hardware and protocol addresses in the sender fields.
        Set the ar$op field to ares_op$REPLY
        Send the packet to the (new) target hardware address on
            the same hardware on which the request was received.


Your question is completely different now, and that is bad form. Please ask a different question in a new question.

You need to follow the packets. If Hb is sending to a different network, then it sends the frame containing the packet to its configured gateway (the router), which routes the packet to the different network, so the new frame containing the packet arrives at the different interface with the MAC address of the router because the router will strip off the original frame containing the original source MAC address that was altered.

Ha receives the frame from the router on its interface, which sends it up the network stack. Ha then processes the datagram, and it sends a response back to Hb out its interface because its internal routing table has that network as a directly connected network.

It sounds like you think that because a packet was received on one interface, it should reply on that same interface, but that is not how it works. Each packet is routed separately, regardless of any packet that may have come before. Your scenario will never send a Packet from Ha to Hb out the interface.

Edit 2:

If you are not seeing a reply on the correct ( interface, then there is something wrong with your host, and its behavior is off-topic here. I have described what a host is supposed to do, but if yours does something different, then you have some misconfiguration, a measurement problem, or the behavior of your host is non-standard. None of those problems are something to ask about here, and since you claim a lab, it would be off-topic for Server Fault, but you could try to ask about it on Super User, Unix & Linux, or Ask Ubuntu.

  • On my Ubuntu 18 machine theres no outgoing reply packet on neither of the two interfaces! And thats the reason of my question :P ...Maybe someone could verify this behavior in his own lab? that would be very lovely :) – fitcfitcfatc Jul 20 '19 at 21:58
  • OK. I have made a second edit, and your question is off-topic again because it is about how your host is behaving, or about how you are measuring the results, neither of which is on-topic here. – Ron Maupin Jul 20 '19 at 22:05
  • Ok, now i see the problem, too. I'm sorry. – fitcfitcfatc Jul 21 '19 at 9:08

First of all MAC address table don't have IP addresses. The thing you describing is ARP table which contains bindings IP to corresponding MACs.

So there is 2 ARP entries static and dynamic one. For most of the time you will be using dynamic so if host receives the same IP address with different MAC address he will just update dynamic ARP entry with new MAC. For Static one host will not respond until you modify by hand arp record.

Reasons that linux host doesn't respond could be more for example if network using DHCP spoofing and DAI it will filter this packets if user will set his address manually instead of using DHCP.

  • Yes i meant the ARP table, but your statement is a bit ambiguous to me. I tought the ARP table only will be updated by ARP replies!? – fitcfitcfatc Jul 19 '19 at 10:26
  • Maybe I made my message too short. So to fill it out: when you change your MAC address you automatically sending ARP message with your IP address and your new MAC. So if other host will receive you ARP message with different MAC address than is in their ARP table they will update it if entry in their table is dynamic. – kubn2 Jul 19 '19 at 10:40
  • Ok, but i think my initial question is still unanswered. "What happens if a host on the network receives an IP packet with a MAC source address that differs from the MAC address in the local ARP address table for that source IP." Based on which reason the host decided to NOT send an response. (Response = ICMP echo reply or TCP SYN/ACK ...etc) – fitcfitcfatc Jul 19 '19 at 12:35
  • This situation can't happen why? Because when you change MAC you sending to hosts in your ARP table information about this. If host that changed his MAC do not hear a reply from some host he marking arp entry in his table as incomplete and discarding this entry so when this host after some time want to send packet to this host he first will send an ARP packet again to it host and during that the other host will update his ARP entry. – kubn2 Jul 19 '19 at 12:45
  • Second situation can be opposite -> when host A changed MAC address but host B didnt hear an update and still have old ARP entry in his table. Now when host B sending packet to host A he will not send ARP because he thinks he have his MAC but he don't. Then after packet is forwarded to host A he will just discard this frame because there will be no match in Layer 2 address. – kubn2 Jul 19 '19 at 12:47

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