Clients in same WLAN can't reach each other

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.

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 ...

I recently started seeing this on my WRT32X (running davidc502's build). Rebooting fixes it for a few hours.

just upgraded to 18.06.1 will see if it's OK now

yes i've done that but it's still irritating ;p

Hello! I am new here. Also experiencing this problem but not sure if I should open an other topic with more precise problem description.

In my case, I clearly identified the problem. I am not so deep in openwrt to know if it is a bug or if it is event possible to have client communication within the same WLAN (if someone knows?) in the following situation:
The SAME wifi adapter is used for setting up:

  • WLAN network
    AND
  • the WLAN up link (client mode to an other wifi router)

In the configuration I have no communication between clients in the WLAN network.
Removing the WLAN uplink (client mode to an other wifi router) resolves the problem.

To solve the problem, I had to use 2 different adapters.

If someone could tell something about this, bug or not possible? Thank you!

I have WRTnode and I have access problem with LEDE. If I configure it AP+STA mode I can't see it from other computer via it's IP. When firewall is disabled, does not helps the situation.
With Barrier Breaker, r41508 it is working.

I have recognised a phenomenon. Lets say I have a router, wrtnode, two PCs.
I don not see luci on PC2 via WRTnode's IP. - default problem
But if I connect with PC1 to wrtnode as AP and ssh into and make ping to PC2, I can reach PC2. During the ping is working I can see luci from PC2, but only when ping is on.
If I kill ping on wrtnode, I am loosing connection from PC2 to wrtnode via IP.
How is it possible this temporal access?

I have checked hairping settings on Barrier Braker. All are 0 and I see it from other client via wlan.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.