Sending ARP reply with arbitrary source MAC

Question

This is a follow-up to my previous question: ARP reply packet does not update ARP cache on Ubuntu. It turned out that my problem was that I was using an arbitrary MAC address as my source MAC (ie. one that doesn't exist on my network, say aa:bb:cc:dd:ee:ff). I could send ARP replies to poison my cache with no problem as long as my source MAC matches with the MAC of my NIC. I tried to manually set my NIC to have an arbitrary MAC address, then send ARP replies using that as my ARP packet's source MAC - also worked.

I am wondering if anybody knows the inner workings of this. Was there some kind of check that prevents packets with mismatched source MAC from being sent? Was it a check between the source MAC of the Ethernet frame vs. the source MAC of the ARP packet? And for the purpose of an experiment that I'm running, is there a way to bypass this restriction?

JY

Answer 1

Various optimizations are possible to make ARP work more efficiently. To start with, once a machine has run ARP, it caches the result in case it needs to contact the same machine shortly. Next time it will find the mapping it its own cache, thus eliminating the need for a second broadcast. In many cases, host 2(receiver) will need to send back a reply, forcing it, too, to run ARP to determine the sender's Ethernet address. This ARP broadcast can be avoided by having sender include its IP-to-Ethernet mapping in the ARP packet.

Quoted from Tanenbaum's Computer Networks, fifth Edition p486-487

So it looks like your receiver fails to resolve MAC of the sender. And Tanenbaum presented a solution to you to avoid this failure.

Answer 2

Was there some kind of check that prevents packets with mismatched source MAC from being sent? Was it a check between the source MAC of the Ethernet frame vs. the source MAC of the ARP packet?

You mention Ubuntu. In Linux, you can send any Ethernet frame (see examples), so internally there is no any kind of such check. But you did not tell how do you attempt to send the spoofed ARP messages; maybe the way you are doing it is limiting your options for the source MAC address.