Why am I not getting an ARP reply with this request?

Question

Using pcap_sendpacket in C, I'm manually sending the following packet on wlan0 (I've left out some fields, but I think they are correct):

(Ethernet layer)
eth src:  <wlan0 MAC address>
eth dest: <wireless router MAC address>
(ARP request layer)
opcode: 1 (Request)
sender_hw: <wlan0 MAC address>
sender_proto: 192.168.1.3 (IP of wlan0)
target_hw: 0 (per usual)
target_proto: 173.194.46.72 (Google.com)

Using Wireshark to listen on wlan0, I expect to see an ARP reply giving me the MAC address of a Google server. However, I am not seeing any ARP replies containing Google's IP whatsoever.

One thing to note is that I am building this packet by intercepting an ARP request sent to a virtual network interface (the packet is generated when I use the ping command from within the virtual netspace), then rewriting the packet and injecting it on wlan0 using pcap, so that I can later get the ARP reply and forward it back to the virtual network. This is why I am relatively confident that the other fields in the packet are correct, since I really didn't modify them.

Does anyone know what might be the problem here? One thing I'm sort of noticing is that I don't have my router's IP address (192.168.1.1) anywhere in that packet; not really sure whether I need that or not.

No... Hmm, do I need to set the `sender_proto` field to the IPv4 of my router relative to the global Internet? — Brandon, Nov 07 '14 at 23:49
You probably need to brush up on your TCP/IP fundamentals. You can only arp for systems on the local network. ARP does not cross a router. If the address is not locally connected you arp for a gateway defined in one of routes. — Zoredache, Nov 07 '14 at 23:52
Ah so I think since these routes aren't defined for the virtual netspace, I just need to spoof an ARP reply, rather than trying to forward the request to wlan0. — Brandon, Nov 07 '14 at 23:59

score 2 · Answer 1 · answered Nov 09 '14 at 23:47

You're _NOT_ getting an ARP-reply, 'cause within your broadcast domain [1] (aka: your local [W]LAN segment) there is _NOT_ an host whose IP address is the one you're ARPing for (173.194.46.72).

To be more detailed, let me add that:

ARP is a Layer-2 protocol [2] and as such, as already mentioned by Zoredache: "...ARP does not cross a router...". An ARP-request tipically is sent via a "broadcast" ethernet frame. That's why it cannot cross the local... broadcast domain;
even tough you can surely ARP-request for whatever IP you prefer (Google's 173.194.46.72 included), you're _NOT_ going to receive any ARP-reply (unless "...Google is on your LAN...", as mentioned in M.Hampton comment above), 'cause in such a case:
- Every host on your LAN will phisically receive and process the broadcast frame generated by your ARP-request. Hence...
- ...every host will discover that it contain an ARP-request for 173.194.46.72. Hence...
- ...as every host on your LAN is configured with a different IP address (unless, again, your "Google");
- no host will send an ARP-reply!

Unfortunately it's not clear, to me, which is exactly the problem you're trying to solve. Anyway you might find useful to briefly investigate:

"gratuitous ARP" [3], that follows a reverse schema with respect to the common ARP-Request=>Arp-Reply you're testing;
"ARP spoofing/poisoning" [4], regarding "denial of service" / "man in the middle" / "session hijacking" attacks you might be suffering;
"ARPing" [5], as a very easy way to send ARP-request and check for ARP-reply. This is very useful, among other cases:
- to test network connection (for hosts connected to local network) even when an IP firewall is configured on the remote host (in other words: you can ARP-ping a locally connected Windows host even when the windows firewall is active);
- to get MAC addresses of offending hosts, when such hosts are configured with the same IP address (you will send ONE ARP-request and get back MULTIPLE ARP-reply);
"Ettercap" [6], "...a comprehensive suite for man in the middle attacks. It features sniffing of live connections, content filtering on the fly and many other interesting tricks. It supports active and passive dissection of many protocols and includes many features for network and host analysis..."