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
      \                /
       \              /
        \            /
         Access Point, AP
         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.
  • ARP starts with an Ethernet broadcast. Are other broadcasts affected? Like ping -b (which doesn't require ARP) once you allow answering broadcasts (sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=0) in peers . Also toggling ap_isolate like told in the answer might change behaviour (but answer talks about a non-existing bridge). multicast (and broadcast) can be handled differently than unicast sometimes in Wifi (related to shared group key etc.)
    – A.B
    Commented Apr 17, 2021 at 17:38
  • @A.B ping -b is working if icmp_echo_ignore_broadcasts=0. Commented Apr 18, 2021 at 11:05
  • Ok I was curious on why would a NIC or driver get a special effect with ARP, but this led nowhere.
    – A.B
    Commented Apr 18, 2021 at 11:11

1 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
  • Thanks for your answer. ap_isolate=0 was already set. And I'm not using a bridged interface. However I found the problem. It was not the configuration, but the driver for the USB Wifi adapter. See my edit above. Commented Apr 17, 2021 at 17:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .