Clients in same WLAN can't reach each other

Just a random thought -- are you using the full hostapd or the mini package? I'm using the full.

Okay, so I was experiencing a similar problem with arp, and with hairpin_mode being set to 0, but only on my 2.4GHz wlan and not on 5GHz (and as in your case, "echo 1 > /sys/devices/virtual/net/br-lan/" resolved the issue, at least until the next restart).

After some experimentation, I deduced that it was the period / decimal point in the interface name that was breaking something, eg:

root@WRT1900ACSv2:~# cat /sys/devices/virtual/net/br-lan/lower_eth0.1/brport/hairpin_mode
root@WRT1900ACSv2:~# cat /sys/devices/virtual/net/br-lan/lower_wlan0-5GHz/brport/hairpin_mode
root@WRT1900ACSv2:~# cat /sys/devices/virtual/net/br-lan/lower_wlan1-2.4GHz/brport/hairpin_mode

root@WRT1900ACSv2:~# cat /sys/devices/virtual/net/br-lan/lower_eth0.1/brport/hairpin_mode
root@WRT1900ACSv2:~# cat /sys/devices/virtual/net/br-lan/lower_wlan0-5.0GHz/brport/hairpin_mode
root@WRT1900ACSv2:~# cat /sys/devices/virtual/net/br-lan/lower_wlan1-2.4GHz/brport/hairpin_mode

root@WRT1900ACSv2:~# cat /sys/devices/virtual/net/br-lan/lower_eth0.1/brport/hairpin_mode
root@WRT1900ACSv2:~# cat /sys/devices/virtual/net/br-lan/lower_wlan0/brport/hairpin_mode
root@WRT1900ACSv2:~# cat /sys/devices/virtual/net/br-lan/lower_wlan1/brport/hairpin_mode

root@WRT1900ACSv2:~# cat /sys/devices/virtual/net/br-lan/lower_eth0.1/brport/hairpin_mode
root@WRT1900ACSv2:~# cat /sys/devices/virtual/net/br-lan/lower_wlan0-5GHz/brport/hairpin_mode
root@WRT1900ACSv2:~# cat /sys/devices/virtual/net/br-lan/lower_wlan1-2p4GHz/brport/hairpin_mode

Not sure if this is the cause of the issue in your case, but might be worth checking...



That was really the cause of the issue!
I had all interfaces named like, so for example wlan.5G. Never thought that this could cause such problems...
Simply replaced the . with - and it works perfectly fine :slight_smile:
Thank you Martin, for finally resolving this!


I discovered this topic when trying to find out why ap_isolate=0 isn't being set in the hostap.conf file. The config looks good ( but it comes out in /var/run/hostapd-phy0.conf as


One workaround is to manually set hairpin_mode using echo "1" > /sys/devices/virtual/net/br-trusted/lower_dual2/brport/hairpin_mode, but it would be nice to find a solution that survives across reboots.

Is this possibly related to the following issue:

What's the current "right way" to have clients on the same ssid communicate with eachother?

I believe the "right way" is to enable "multicast to unicast" which will force hairpin mode on, and not to worry about hostapd.conf, where isolate will always be set henceforth.

The only reason not to enable "multicast to unicast" is if you are doing something like distributing video to multiple displays all displaying the same feed. In almost every normal scenario, "multicast to unicast" will save RF bandwdth.

Thanks @skids.

Could it be that the documentation needs an update? I'd be happy to do this but might need some guidance on the specific implications of hairpin vs mcast_to_ucast.

As it is, the following config seems to work and has Chromecast's finding each other on the same wifi point.

is isolate now deprecated?

This is happening to Atheros or Broadcom?
Archer C5 v1 is Atheros:
but you are talking about some Broadcom too

This one is Marvell

Marvell too...

Do you know if Is this a problem of driver, firmware-chipset compatibility, configuration or what?

The situation is this:

multicast_to_unicast is desireable

in order for multicast_to_unicast to work, all WiFi traffic must go to the linux bridge interface

"isolate" hostapd.conf and "isolate" in uci should not be confused

isolate=0 in hostapd.conf prevents some client-to-client traffic from going to the
linux bridge

once you turn on isolate=1 in hostapd.conf, all wifi traffic goes to the linux bridge,
but if you want clients to talk to each other, you have to tell the linux bridge to

isolate=1 in hostapd.conf is by default always on.

hairpin=1 on the linux bridge is by default automatically controlled by the scripts
based on your settings for unicast_to_multicast... and maybe the uci isolate option...
my memory is starting to get fuzzy at this point.

1 Like

@skids thanks for the heads-up. I've now updated the bridge config to include the hairpin settings and mcast_to_ucast

However this does not update /sys/devices/virtual/net/br-trusted/lower_dual2/brport/hairpin_mode

I'm inclined to mark this as a bug since I'm pretty sure I'm setting the right bits but it never works:


Setting manually with echo 1 > /sys/devices/virtual/net/br-trusted/lower_dual2/brport/hairpin_mode and everything magically works.

Am I missing something? Full config is at

1 Like

Why do you want to set hairpin mode manually? I don't think this is possible through UCI and it should be on by default.
I did a quick test now with my working setup (changed interface names), multicast to unicast is always on and hairpin mode depends on isolate. hairpin is enabled if isolate is disabled (default) and hairpin is disabled when isolate=1, effectively blocking multicast/ARP traffic.

1 Like

@Jake - I really don't want to be setting it manually. The problem is that isolate="0" isn't setting it.

1 Like

I have exactly this problem too on Reboot (17.01.4, r3560-79f57e422d).

On my 2.4GHz radio I have a second SSID with option isolate 1. The main SSID does not have this option. /sys/devices/virtual/net/br-lan/lower_wlan0/brport/hairpin_mode shows 1 like it should. multicast_to_unicast is 1. and /var/run/hostapd-phy0.conf shows ap_isolate=1 on all SSID's like it should (because it should be hairpinned via bridge). Still, the Wi-Fi client to client traffic fails. I see my laptop send ARP out but never gets a reply from other Wi-Fi clients. This looks like a bug to me. Or an undocumented feature :slight_smile:

1 Like

I'm also running 17.01.4, but I had the same under previous releases too. Works perfectly for 6-10 days, then ARP requests to find my Wireless Printer and Raspberry PI no longer get replies. From the router itself, everything is good!

My config is also using 2 SSID on the 2.4Ghz radio...

For now, my workaround is to run the "wifi" command from the cron schedule every night @1am. It reloads wifi config and I get back my wireless printer. It does kick out every WIFI users for a few secs though


I'm running 17.01.4 and have my LAN bridged to both the 2.4GHz and 5GHz WLANs. I'm seeing exactly the same thing - works fine for a few days then my desktop on the LAN can't get ARP replies from my wireless devices. But the wireless devices can still access my file server on the LAN and so I can still access them from there and from the router itself. Bouncing the wifi fixes the problem, so I've added a cron job to do that.

1 Like

Same problem (17.01.2, r3435-65eec8bd5f) on a Linksys WRT AC3200. Wifi clients can't see each other. I've looked at the values in /sys/devices/*/hairpin_mode, multicast_to_unicast, isolate_mode and they match what people say are the "correct values". Rebooting will make it work for a hour or day or two, then it stops again. Even when it is working, ping times between Wifi clients seem long (200-300ms).

Settings appear to be the same before and after boot:

root@openWRT:/sys# for f in $(find . -name hairpin_mode -o -name multicast_to_unicast -o -name isolate_mode); do echo $f; cat $f; done

Is there any hope that a newer version fixes this? If not, I'm going to give up and to go back to my old router.

1 Like

Same ping times when using the "wifi" command?

when it is working, ping times between Wifi clients seem long (200-300ms).

Same ping times when using the “wifi” command?

I don't know what you mean by 'when using the "wifi" command'.

I've been doing some additional testing, and it looks like the long ping times happen with certain wifi clients even when pinged from the wired network.

It also seems like when it stops working, clients on the 5GHz wlan can talk to each other, but clients on the 5GHz wlan can't talk to clients on the 2.4GHz wlan. Wired clients can talk to all wifi clients.

The wifi command, when issued with no arguments, will reload your wifi. Resets things & allows your clients to see each other again. When I first ran into this issue a reboot oddly didn't help but issuing the wifi command did.

wifi --help
Usage: /sbin/wifi [config|down|reload|status]
enables (default), disables or configures devices not yet configured.

The wifi command didn't seem to affect ping times. Rebooting did appear to reduce ping times for one client, but another.

After spending a couple more hours fighting with it, I had to revert to using a Netgear WNDR3800 with OpenWRT 15.05.1. The Linksys WRT AC3200 running 17.01.2 would only pass packets between wifi clients for a few hours at a time, and having to restart/reboot several times a day isn't viable. The 2.4GHZ radio wold also sometimes lock up completely (though that only happens a few times a month rather than several times a day).

Funny issue, encountering the same, brand new WRT AC3200 with latest LEDE.
Had very inconsistent, slow inter-device bandwidth and latency.
Could not proof that it has something to do with the radio-device (2,4ghz vs. 5ghz).

Nevertheless, I can clearly confirm that the following solves the whole issue (the dirty way I believe):

for fn in /sys/devices/virtual/net/br-lan/*/brport/{hairpin_mode,multicast_to_unicast,isolate_mode}
echo "$fn "
(echo $fn | grep 'isolate' && echo -n 0 | tee $fn) || echo -n 1 > $fn

hairpin_mode is the most important one with the highest impact (no vs. good communication)
multicast_to_unicast seems to do something, but not enough evidence collected
isolate_mode HAS to be '0' or no communication will be there between clients

Clearly this is far from fancy, so: How do I make sure LEDE is caring about these settings?