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
10.2.0.5 interface, which sends it up the network stack.
Ha then processes the datagram, and it sends a response back to
Hb out its
10.1.0.5 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
Hb out the
If you are not seeing a reply on the correct (
10.1.0.5) 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.