Clients in same WLAN can't reach each other

I checked/tried that already (look at the 1. reply).

Which scripts do you mean? I am currently on LEDE Reboot 17.01.2, so it should be not too old... on 17.01-rc1 i also did a factory reset and it did not even work with almost default config.

Do you get also hairpin_mode = 0 ?

No, my hairpin_mode gets set to 1. The scripts are in /lib/netifd/ ... they are a bit tangled and hard to read. Also some of the logic is in binaries. There might be some sort of dependence on multicast_to_unicast -- if you've turned it off somehow, turn it back on.

Other than that, I dunno, this stuff is more or less new to me as well.

Yes, in netifd-wireless.sh multicast_to_unicast seems to be related to isolate.
Okay, but how can i turn multicast_to_unicast on? I did not turn it off afaik.
The only option i could find was directly writing sysfs again...

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/lower_wlan.name/brport/hairpin_mode" 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
0
root@WRT1900ACSv2:~# cat /sys/devices/virtual/net/br-lan/lower_wlan0-5GHz/brport/hairpin_mode
1
root@WRT1900ACSv2:~# cat /sys/devices/virtual/net/br-lan/lower_wlan1-2.4GHz/brport/hairpin_mode
0


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


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


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

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

Martin.

2 Likes

That was really the cause of the issue!
I had all interfaces named like wlan.xyz, 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!

2 Likes

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 (https://github.com/imaginator/home-network/blob/master/w8970_w8980.settings#L125) but it comes out in /var/run/hostapd-phy0.conf as

interface=dual2
ctrl_interface=/var/run/hostapd
ap_isolate=1
disassoc_low_ack=1
preamble=1
wmm_enabled=1
ignore_broadcast_ssid=0
uapsd_advertisement_enabled=1

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: https://bugs.lede-project.org/index.php?do=details&task_id=272?

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: https://wikidevi.com/wiki/TP-LINK_Archer_C5_v1.x
but you are talking about some Broadcom too https://wikidevi.com/wiki/TP-LINK_Archer_C5_v2.x

This one is Marvell https://wikidevi.com/wiki/Linksys_WRT1200AC_v2

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
hairpin=1.

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:

and

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 https://github.com/imaginator/home-network/blob/master/w8970_w8980.settings

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

3 Likes

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
./devices/platform/soc/soc:pcie-controller/pci0000:00/0000:00:01.0/0000:01:00.0/net/wlan0/brport/isolate_mode
0
./devices/platform/soc/soc:pcie-controller/pci0000:00/0000:00:01.0/0000:01:00.0/net/wlan0/brport/hairpin_mode
1
./devices/platform/soc/soc:pcie-controller/pci0000:00/0000:00:01.0/0000:01:00.0/net/wlan0/brport/multicast_to_unicast
1
./devices/platform/soc/soc:pcie-controller/pci0000:00/0000:00:02.0/0000:02:00.0/net/wlan1/brport/isolate_mode
0
./devices/platform/soc/soc:pcie-controller/pci0000:00/0000:00:02.0/0000:02:00.0/net/wlan1/brport/hairpin_mode
1
./devices/platform/soc/soc:pcie-controller/pci0000:00/0000:00:02.0/0000:02:00.0/net/wlan1/brport/multicast_to_unicast
1
./devices/platform/soc/soc:internal-regs/f10d8000.sdhci/mmc_host/mmc0/mmc0:0001/mmc0:0001:1/net/wlan2/brport/isolate_mode
0
./devices/platform/soc/soc:internal-regs/f10d8000.sdhci/mmc_host/mmc0/mmc0:0001/mmc0:0001:1/net/wlan2/brport/hairpin_mode
1
./devices/platform/soc/soc:internal-regs/f10d8000.sdhci/mmc_host/mmc0/mmc0:0001/mmc0:0001:1/net/wlan2/brport/multicast_to_unicast
1
./devices/platform/soc/soc:internal-regs/f1034000.ethernet/net/eth0/brport/isolate_mode
0
./devices/platform/soc/soc:internal-regs/f1034000.ethernet/net/eth0/brport/hairpin_mode
0
./devices/platform/soc/soc:internal-regs/f1034000.ethernet/net/eth0/brport/multicast_to_unicast
0
./kernel/debug/ieee80211/phy1/netdev:wlan1/multicast_to_unicast
0x0
./kernel/debug/ieee80211/phy0/netdev:wlan0/multicast_to_unicast
0x0

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?