Clients cannot connect to each other on WLAN. No reply on ARP requests

Question

I have install a WLAN with an access point which connects the clients to the internet. At first all seemed to work correctly until I noticed that the clients can not communicate with each other.

Here are the details: One machines is connected to the internet via eth0, and acts as an access point via wlan1. It is running hostapd and dnsmasq and it's using NAT to connect the other clients to the internet.

Client A             Client B
192.168.1.143        192.168.1.235
      \                /
       \              /
        \            /
         Access Point, AP
         wlan1: 192.168.1.1
         eth0:  192.168.0.xxx

So far, the clients can connect successfully to the internet. They can connect (eg. via ssh) to the access point. And the access point can ssh to the clients.

Now the problem is that client A cannot connect to client B and vice versa. Using tcpdump on the access point I see that client A is sending ARP requests for client B. But client B never receives these requests and thus cannot reply. Therefore the arp table entry for client B is incomplete (and vice versa).

For testing purpose I set the arp table entries manually for both clients with arp -s <ip> <hw_addr>. And now everything is working successfully. The clients can connect to each other and they can connect to the intenet. But actually I don't want to set arp table entries manually for all client machines.

Now, my question is: Where's the problem here? How are arp tables supposed to be updated automatically? Where should I look into? Is it a problem on the access point (routing table, hostapd, dnsmasq, ...)? Or is it a problem on the client machines?

ps: There are no arptables rules installed on any machine:

$ arptables -L
Chain INPUT (policy ACCEPT)

Chain OUTPUT (policy ACCEPT)

Edit: Finally I found the problem:

After rechecking the configuration I eventually tested it with another USB Wifi adapter. And I was really surprised to see that everything was working then. ARP requests were being received and answered by the clients. Ping and ssh between arbitrary clients was working, too.

Just to be certain, I changed back to the first USB Wifi adapter. And again ARP requests were not received (and answered) by the clients. Thus I can confirm that it was not an issue with configuration of hostapd or with kernel arp tables. The problem was the driver for the Wifi adapter.

Here are the details:

1. ID 0bda:8812 Realtek Semiconductor Corp. RTL8812AU 802.11a/b/g/n/ac 2T2R DB WLAN Adapter

   • Not working correctly.
   • ARP requests are received by the access point, but they are not received by the clients.

2. ID 0bda:b812 Realtek Semiconductor Corp.

   • Working satisfactorily.
   • ARP requests and ARP replies between arbitrary clients are working correctly.

Answer 1

You can either set the configuration so that ap_isolate = 0.

Or set ap_isolate = 1 and then hair_mode (that asks the bridge to send the frames back over the same interface):

echo 1 > /sys/devices/virtual/net/br-lan/lower_wlan.name/brport/hairpin_mode

Answer 2

I ran into the same issue as described above: broadcasted ARP requests were not replied from one client made to another client.  However, ARP requests from a client to the AP (and vice versa) worked.

Tried every possible hostap configuration option without success.  The solution was to use another Wi-Fi adapter (tested multiple times):

• The adapter that did not work was a TP-Link TL-WN722N v2 (chipset: Realtek RTL8188EU) + installed corresponding driver from the aircrack-ng repo
• The predecessor TP-Link TL-WN722N v1 (chipset: Atheros Communications AR9271) worked as expected.