Clients in same WLAN can't reach each other

I have the exact same problem:
I set up a bridge (layer 3) with lan/wlan interfaces.
Clients within wlan cannot reach each other, clients within LAN cannot reach each other. LAN Clients can reach WLAN clients and vice versa. Of course all can reach the router itself.
I used the latest firmware (lede-17.01.0-r3205-59508e3-brcm47xx-mips74k-netgear-wnr3500l-v1-other-regions-squashfs.chk) on a Netgear WNR3500l and upgraded from a DD-WRT image - so the config startet from scratch. I also had no "isolated"-option around in configs.
I had to downgrade back to DD-WRT.

HTH!

I had the same problem, but only while I had set up a second network ('v-test', as a guest network) on the same device (radio0). The first network was connected to 'lan' all the time, unlike 'v-test', which should only provide Internet access to connected clients (no access to other computers on the 'lan'). While 'v-test' was enabled, the overview page would not show clients connected to my master network on radio0 - only those connected via cable, or on radio1 (5 GHz). I had not expected this behaviour, and I don't know if it can be considered a bug, or if I did something wrong. I'm using LEDE 17.01.0.

1 Like

Any clues on this problem?

I found your bug and added supplemental information in a comment. Are you using version 17.01 or version 17.01.1? I believe 17.01 didn't suffer from this problem. Please update bug report accordingly. Thank!

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?