Woah! Thanks for taking the time to write the detailed response. Will take a look at the source code. Really appreciate the effort ❤️

I added more comments on the original post which describes the situation a bit more.

Don’t know what’s a good way to get the comments linked to this post.

Do take a look if you are interested.

Standards are set of rules. But still different vendors implement them separately. For e.g. TCP/IP stack implementation is a bit different in Windows and Linux but end user generally never realises this because it’s close enough that things still work. I want to know what is the sequence of events when Linux creates a Response packet for a ping Request it received.

I recently tested this using wireshark. When I run packet capture on nic1 of dstPC I see ping request packets coming, but no response packets leaving the interface. On nic2 I don’t see any packets leaving either. So kind of stumped what is happening. It seems the computer just drops the response packet and it never makes it till any nic. But still don’t have a good explanation of WHY the packet gets dropped.

OK this is what I was thinking too. So consider this scenario:

srcPCnic1 - 192.168.1.100/24 DG: 192.168.1.1 dstPCnic1 - 192.168.2.100/24 dstPCnic2 - 192.168.1.101/24 DG: 192.168.1.1

Topology: srcPCnic1 -> RTR -> dstPCnic1 Assume srcPCnic1 is also connected to dstPCnic2 via a switch. (Sorry if its difficult to imagine with the crude description)

On srcPC execute: ping 192.168.2.100 RTR will route the packet to dstPC. dstPC receives the packet on nic1. dstPC sends the Response packet via nic2.

Is the above understanding correct?