Clients in same WLAN can't reach each other

ap_isolate is set to 1 if not defined, at least for my setup. Please add

isolate=0

to your wlan interface.

"option isolate 0" and "option isolate 1" makes no difference on my device and "ap_isolate" is always set to 1 in /tmp/run/hostapd-phy0.conf
:astonished:

Dont understand why...???

One could look at the script that creates the hostapd.conf, but currently i doesn´t remeber where this bash script is located...

lede 17.01.4
R7800
same problem
sad :frowning:

/lib/netifd/netifd-wireless.sh

Thanks.
I found the script for hostapt in the same folder...

/lib/netifd/hostapd.sh -> final rom
package/network/services/hostapd/files/hostapd.sh -> open wrt src

Parse of config looks good to me, don´t know why i always get ap_isolate=1 in hostapd-X.conf

Looking at it here, https://openwrt.org/docs/guide-user/network/wifi/basic says default for isolate is 0, yet I see ap_isolate=1 in my hostapd-phy1.conf

Adding option isolate '0' to the AP definition doesn't change the contents of hostapd-phy1.conf here either.

(on master here of a week or so ago)

You guys should read the earlier posts in this thread about the difference between isolate in uci and ap_isolate for hostapd

Since it's not documented in the wiki, and there's a year's worth of posts here, from June, 2017:

find /sys/devices -name hairpin_mode -exec sh -c 'printf "%s: %s\n" {} $( cat {} )' \;
1 Like

Experiencing the same issue on a Linksys WRT1900ACSv1 / LEDE Reboot 17.01.4 r3560-79f57e422d.

Some WiFi clients (XP client in particular) cannot access Windows' Shares, others cannot "see" Network Printers.

Results / Configs

/sys/devices -> hairpin_mode
root@LEDE:/etc/config# find /sys/devices -name hairpin_mode -exec sh -c 'printf "%s: %s\n" {} $( cat {} )' \;
/sys/devices/platform/soc/soc:pcie-controller/pci0000:00/0000:00:01.0/0000:01:00.0/net/wlan0/brport/hairpin_mode: 1
/sys/devices/platform/soc/soc:pcie-controller/pci0000:00/0000:00:02.0/0000:02:00.0/net/wlan1/brport/hairpin_mode: 1
/sys/devices/platform/soc/soc:internal-regs/f1034000.ethernet/net/eth0/brport/hairpin_mode: 0

/sys -> hairpin_mode, multicast_to_unicast, isolate_mode
root@LEDE:/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/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

/tmp/run/hostapd-phy0.conf
driver=nl80211
logger_syslog=127
logger_syslog_level=2
logger_stdout=127
logger_stdout_level=2
country_code=US
ieee80211d=1
ieee80211h=1
hw_mode=a
beacon_int=100
channel=36


ieee80211n=1
ht_coex=0
ht_capab=[HT40+][LDPC][SHORT-GI-20][SHORT-GI-40][DSSS_CCK-40]
vht_oper_chwidth=1
vht_oper_centr_freq_seg0_idx=42
ieee80211ac=1
vht_capab=[RXLDPC][SHORT-GI-80][SU-BEAMFORMER][SU-BEAMFORMEE][RX-ANTENNA-PATTERN][TX-ANTENNA-PATTERN][RX-STBC-1][MAX-A-MPDU-LEN-EXP7]

interface=wlan0
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
wpa_passphrase=REDACTED
auth_algs=1
wpa=2
wpa_pairwise=CCMP
ssid=MANUMACH
bridge=br-lan
wpa_disable_eapol_key_retries=0
wpa_key_mgmt=WPA-PSK
okc=0
disable_pmksa_caching=1
bssid=REDACTED

/tmp/run/hostapd-phy1.conf
driver=nl80211
logger_syslog=127
logger_syslog_level=2
logger_stdout=127
logger_stdout_level=2
country_code=US
ieee80211d=1
hw_mode=g
beacon_int=100
channel=11


ieee80211n=1
ht_coex=0
ht_capab=[LDPC][SHORT-GI-20][SHORT-GI-40][DSSS_CCK-40]

interface=wlan1
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
wpa_passphrase=REDACTED
auth_algs=1
wpa=2
wpa_pairwise=CCMP
ssid=MANUMACH
bridge=br-lan
wpa_disable_eapol_key_retries=0
wpa_key_mgmt=WPA-PSK
okc=0
disable_pmksa_caching=1
bssid=REDACTED

it seems to me that when the wifi goes to "isolation mode", even the connection wifi to wired gets some problem.
It is not impossible like wifi to wifi, but it returns random errors.

I also have to admit that i remember in the last months with ddwrt i had the same problem (i had to periodically reboot the router since i could not access my wifi-connected raspis)

anyone without guest lan is experiencing this?

Sorry to be so hopelessly noobish but I feel that if this issue has been resolved, then a clear summary of the solution could do with being added to close this thread. I'm so far out of my depth, I can't identify which post if any provides the solution despite numerous repeat readings of the entire topic.

If, on the other hand, this is still unresolved then I can confirm that the default config of LEDE Reboot 17.01.4 on a Linksys WRT1900ACSv2 suffers from the problem of Wireless clients not being able to communicate with each other. For example, a laptop cannot view a wireless IP camera unless connected to the router via ethernet. My guess is that such a common use-case would result in this being solved by now. I hope I'm not wrong.

@RadianM - the way I understood it is the following:

  • there is a little known per-iface option option multicast_to_unicast which - if unset - defaults to true
    • that feature implies mac80211-level client isolation and handles client<>client forwarding using a mechanism called "bridge hairpinning" instead
    • in theory this should not prevent client<>client communication and work the same way as an unisolated wireless network but it seems that - at least on 17.04 - there might be some kernel level issues preventing that from working properly
  • since the multicast_to_unicast option is neither mentioned in the default wifi config, nor exposed in LuCI, users are not aware of it and are unable to disable it (without knowing that it exists + SSH access)
    • the implicitely enabled isolate option is confusing as it is added despite option isolate 0, due to the implicit-enabled-if-absent multicast_to_unicast
  • a workaround is to manually add option multicast_to_unicast 0 to all affected config wifi-iface sections
  • a specific fix has not been added to OpenWrt/LEDE yet
    • for LEDE 17.01.5 a likely fix will be disabling this feature by default + exposing the option in LuCI for users to be to control it
    • for OpenWrt 18.06 and master it needs to be confirmed if there is still an isolation problem

Someone please correct me if the above is wrong.

1 Like

i've not digged inside my router, but as soon as i went from 17.01.4 to something newer i stopped having this sort of problems.

One addition would be the confusion around the "isolate" UCI parameter, presently documented at https://openwrt.org/docs/guide-user/network/wifi/basic

The bug reported in FS #714 is still present in 18.06 RC1, and leads to issues like WiFi printers no longer being reachable until a reboot or a 'wifi' command to restart the wifi subsystem.

To be clear, this bug is not a configuration bug, it is a time-based loss of functionality that works fine when first booted.

This is true. This is probably why the developers can't reproduce the bug.

After a fresh boot I can ping my devices connected to the router, but after a few hours they can't see each other anymore.

Example - 192.168.1.2 is my desktop-pc wired to eth1 and 192.168.1.3 is my android phone connected to ath1. After a fresh boot I get:

ping 192.168.1.3
Pinging 192.168.1.3 with 32 bytes of data:
Reply from 192.168.1.3: bytes=32 time=125ms TTL=44
Reply from 192.168.1.3: bytes=32 time=125ms TTL=44
Reply from 192.168.1.3: bytes=32 time=124ms TTL=44
Reply from 192.168.1.3: bytes=32 time=124ms TTL=44

Ping statistics for 192.168.1.3:
	Packets: Sent = 4, Received = 4, Lost = 0 (0% loss).
Approximate round trip times in milli-seconds:
	 Minimum = 124ms, Maximum = 125ms, Average = 124ms

Then after a few hours:

ping 192.168.1.3
Pinging 192.168.1.3 with 32 bytes of data:
Reply from 192.168.1.2: Destination host unreachable.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 192.168.1.3:
	Packets: Sent = 4, Received = 1, Lost = 3 (75% loss).

If I try pinging 192.168.1.3 again I get Reply from 192.168.1.2: Destination host unreachable. all four times.

I don't understand why ping from my desktop resolves 192.168.1.3 as itself and pings 192.168.1.2 instead, obviously a obscure bug in the router.

I already tried:

echo 1 > /sys/devices/virtual/net/br0/lower_ath0/brport/hairpin_mode
echo 1 > /sys/devices/virtual/net/br0/lower_eth1/brport/hairpin_mode

and

swconfig dev eth0 set enable_vlan 1
swconfig dev eth0 set apply

Setting hairpin mode to 1 on eth1 causes all my LAN to loose connectivity to the router, can't even ping the gateway. Same bug happens on DD-WRT since it uses the same switch drivers.

This causes a series of problems, devices can't see each other for syncing anymore, printers cannot be found, remote control on demand can't reach the target devices waiting the requests anymore and much more.

1 Like

You get a response from your local network stack, this is as expected for "Destination host unreachable", not a obscure router bug. :wink:
Probably because it sends ARP requests and when multicast does not go through it is unable to resolve the destination MAC address.

My bug report might be misleading now though. I wrote it because of the problem caused by some characters in the interface names. After i renamed the wifi interfaces i never had such problems anymore, my Archer C5 has more than 200 days uptime today (still on 17.01.4) and works prefectly fine. Also LAN ←→ WLAN always worked for me, only between WLAN clients was no connection.

As far as i understand it, most people here experience a different bug, that comes after a somewhat random time and that affects different wired/wireless combinations.
It would probaly be helpful to try the workaround that Jow suggested here:

To make sure that it is really caused by this feature.

Must be a different root issue then, as my Wifi name is four alphabetic characters.

Carefully re-reading your bug report, I see there is no time component, it just did not work from the outset. Several of us conflated the loss of functionality similarity, but for us, everything works for 24 to 48 hrs, then mDNS (and other multicast) stops working.

So we need a new bug report focused specifically on the time-based loss of functionality, I'll compose one in the next day or so.

1 Like

UP

I've the same issue on may 1200ac... (v 17.01.4 )

cannot ping from wlan to wlan.

root@spaceship:/# for f in $(find . -name hairpin_mode -o -name multicast_to_unicast -o -name isolate_mode); do echo $f; cat $f; done
./sys/devices/platform/soc/soc:pcie-controller/pci0000:00/0000:00:01.0/0000:01:00.0/net/wlan0/brport/isolate_mode
0
./sys/devices/platform/soc/soc:pcie-controller/pci0000:00/0000:00:01.0/0000:01:00.0/net/wlan0/brport/hairpin_mode
1
./sys/devices/platform/soc/soc:pcie-controller/pci0000:00/0000:00:01.0/0000:01:00.0/net/wlan0/brport/multicast_to_unicast
1
./sys/devices/platform/soc/soc:pcie-controller/pci0000:00/0000:00:02.0/0000:02:00.0/net/wlan1/brport/isolate_mode
0
./sys/devices/platform/soc/soc:pcie-controller/pci0000:00/0000:00:02.0/0000:02:00.0/net/wlan1/brport/hairpin_mode
1
./sys/devices/platform/soc/soc:pcie-controller/pci0000:00/0000:00:02.0/0000:02:00.0/net/wlan1/brport/multicast_to_unicast
1
./sys/devices/platform/soc/soc:internal-regs/f1034000.ethernet/net/eth0/brport/isolate_mode
0
./sys/devices/platform/soc/soc:internal-regs/f1034000.ethernet/net/eth0/brport/hairpin_mode
0
./sys/devices/platform/soc/soc:internal-regs/f1034000.ethernet/net/eth0/brport/multicast_to_unicast
0
./sys/kernel/debug/ieee80211/phy1/netdev:wlan1/multicast_to_unicast
0x0
./sys/kernel/debug/ieee80211/phy0/netdev:wlan0/multicast_to_unicast
0x0

I'm not sure what I ve to do ...