Clients in same WLAN can't reach each other

This is my bug report: https://bugs.lede-project.org/index.php?do=details&task_id=714
The real problem is that ARP broadcasts dont get delivered to other clients... but still no idea what causes this.
I had any LEDE version that i could find, did a reset to default settings, it is all the same.

It might be worth checking how things are actually set in sysfs.

As I understand things, there are 3 "isolation" settings... first there is an internal
hostapd setting (ap_isolate=1), which should nowadays always be set on. This
prevents hostapd from forwarding between wifi clients internally. Instead what it does
is forward all the traffic to the br- interface and let that decide what to do with it, so that
multicast-to-unicast transforms may be performed to increase common-case
performance... and for security reasons.

The second setting is the per-port hairpinning mode. This is usually set to off
on wired or WDS ports and on on client wlan ports. If it is set to off on the client
WLAN ports, clients will not be allowed to talk to each other. This is usually what
you are setting (nowadays) when you ask for client isolation in /etc/config/wireless.

Finally there is the virtual interface isolate mode which is more aimed towards
containers/vms but can be used as a paranoia switch to prevent traffic from
ever crossing between different bridges. Or something like that.

And in addition to this, there is the multicast to unicast setting which should
usualy be on, unless you actually have managed to herd more than a handlful
of clients who are all interested in the same multcast stream onto the same
AP, which is rare and about the only case where sending multicasts out as
RF multicasts is actually more efficient than just sending each client its own
unicast copy.

I don't have this problem. This is what my relevant sysfs nodes say:

root@UUPMAP11:~# cat /sys/devices/virtual/net/br-vlan2/lower_wlan0ssid2/brport/hairpin_mode
1
root@UUPMAP11:~# cat /sys/devices/virtual/net/br-vlan2/lower_eth0.2/brport/hairpin_mode
0
root@UUPMAP11:~# cat /sys/devices/virtual/net/br-vlan2/lower_wlan0ssid2/brport/multicast_to_unicast
1
root@UUPMAP11:~# cat /sys/devices/virtual/net/br-vlan2/lower_eth0.2/brport/multicast_to_unicast
0
root@UUPMAP11:~# cat /sys/devices/virtual/net/br-vlan2/lower_wlan0ssid2/brport/isolate_mode
0
root@UUPMAP11:~# cat /sys/devices/virtual/net/br-vlan2/lower_eth0.2/brport/isolate_mode
0

I don't know how to check the actual state of the internal hostapd setting, but you should
see ap_isolate=1 always in /var/run/hostapd-phy* on all SSIDs unless you are doing something unusual,
even if you did not specify isolate in /etc/config/wireless. As noted above, selecting isolate should
change the value of the hairpin settings from 1 to 0.

(caveat: I'm testing ebtables-dhcpsnooping, so I also have some ebtables rules in the mix.)

5 Likes

Thanks for the detailed explanation, really helpful.
I get on all briges, wlan and eth interfaces the same:
hairpin_mode = 0 multicast_to_unicast = 0 isolate_mode = 0

So i simply set it to 1:
echo 1 > /sys/devices/virtual/net/br-lan/lower_wlan.name/brport/hairpin_mode
And it works immediately!

But why is this off and what is the proper way to change this?

I'm experiencing the same issue on 17.01.0 with a Linksys WRT 1200 AC. Unfortunately changing the hairpin_mode did not lead to any recognizable change.

Check /etc/config/wireless. If option 'isolate' '1' appears, remove it or set it to 0. Or use the uci or LUCI knobs for the same setting.

If the setting does not appear or is already 0 and you still get hairpin_mode=0, maybe your scripts are old?

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