What causes dropping of ARP response packets in a wireless network?

Question

I have a network of wireless access points (APs) in my local area network (LAN).

Some PCs in the network can get ping responses from some other PCs/devices in the network but not some others. I have not found a reliable pattern but in brief it may be something like this:

Say we have a computer Alice, a Wifi AP Bob, and another Wifi AP/device Charlie.

Alice can ping to Bob, Bob can ping to Charlie, but Alice cannot ping to Charlie. ("ping" meaning able to get ping responses) I have already disabled all firewalls, and allowed all ICMP responses.

With the help of Wireshark and tcpdump, I have deduced that the ARP request (opcode 1) packet from Alice was able to reach the intended destination Charlie, and Charlie sent back the ARP response (opcode 2) packet which did not reach Alice.

What could be the possible technical shortcomings resulting in such an error?

How can I debug this situation?

Assuming that I have some programmatic control because I am using OpenWRT, how can I solve this problem?

The funny thing is that when I changed the name of my Windows 8 PC, this problem was rectified. Not sure if this is a case of post hoc ergo propter hoc.

Update: The APs/devices/PCs are on the same subnet, linked using bridge mode.

Answer 1

While I'm not super familiar with advanced configuration on OpenWRT (it's on my to-do-list for geek projects), my first piece of advice would be to ensure that you're not doing NAT on "Bob". If Alice were on the LAN side of a WAP, and Charlie was on the WAN side, then Alice would be able to ping Charlie but not vice versa. That's the inherent firewall that NAT provides.

For this not to be the case, all of your APs have to be operating in some form of "bridge" mode or "access point" mode. This means that the device acts as more or less a packet forwarder - it does not do any routing or packet inspection of its own. The easiest way to achieve this on cheaper routers is to disable the DHCP server in the router and then connect one of the LAN ports to your network (and also ensure that the router's LAN IP won't conflict with your actual gateway). You would leave the WAN port hanging. If the router complains (most don't but some do), set the Internet connection to a static IP and use something like 223.255.255.254 with a 255.255.255.252 subnet mask for the address and 223.255.255.253 for gateway. (Trivia: that's the last Class C subnet of the smallest possible size.)

The other possibility could be a subnet mask mismatch. Every computer on the same network needs to have the same subnet mask configured (along with being in the same actual network of course.) The computer uses the subnet mask to determine not only the IP broadcast address but also to determine whether broadcast packets received should be processed by the network stack (i.e. if broadcast packets for IPs that would fall outside the address and subnet mask configured on the device, many devices will ignore the packet.)

Hope this helps at least somewhat.

Answer 2

What causes dropping of ARP response packets in a wireless network?

Nothing. If we were witnessing proper packet dropping, there would be no reason for them to be preferentially dropped. In the presence of a faulty communication line, ARP packets are no different than UDP, TCP, and whatnot. But, since you do not claim that the line is slow, there is no real reason to suspect true packet dropping.

The reason why packets do not reach their intended target is then that they are mis-routed. However, you have pointed out that the packets that are magically disappearing are ARP packets, which need no proper routing because they spontaneously fill the whole subnet they belong to.

Hence the pcs are (most likely) members of two different subnets. ARP packets do not cross gateways, and one reason for them to be dropped is that they fill their own subnet, find no respondent, then disappear without crossing the gateway separating the two different subnets.

Belonging to two separate subnets would be masked, so to say, if you were to use names instead of IP addresses. If instead you were to use IP addresses, you would have realized immediately that the two pcs are on different subnets. Hence my question above.

Can you get around this problem? Of course you can. You will have to identify the gateway of the subnet which cannot be reached (let's call it G2), allow connections to come in from the larger LAN, and then instruct the gateway of your whole LAN (G1, the one immediately behind your modem, or your ADSL router, whichever) that the route to this subnet is not through itself, G1, but through G2.