FS#714 - ARP/Broadcast does not reach other clients in the same WLAN

[openwrt-bot]

Jakeler:

I have the default bridge with ethernet and WLAN in it. When i try to send data from a client to another, both connected to the same WLAN SSID, it doesn't work (Destination unreachable).
Wireshark shows that it sends endless ARP requests to Broadcast, but the other clients in that WLAN never get it (and therefore can't answer). The broadcast gets still delivery to every client connected through Ethernet. If i create a second WLAN SSID (even on the same adapter) and and add it to the bridge, it gets also all broadcast packets from the other WLAN...
So if i put the 2 clients in different WLAN SSIDs or ethernet they get the broadcast from each other, but not when both are connected to the same.

The isolate option is not set in the wireless config.
Archer C5 v1 with latest LEDE snapshot (no difference to 17.01 stable or rc).

[openwrt-bot]

vista178:

I'm having the same problem with my TP-Link TL-WDR4300 v1.

Firmware version: LEDE Reboot 17.01.1 r3316-7eb58cf109

This appears to be a regression from 17.01.

OP can you confirm that you are using 17.01.1 and not 17.01.

[openwrt-bot]

dh-harald:

I've same problem with Mikrotik hAP ac.
I'm using LEDE Reboot snapshot from master (currently: r4322-f500799)
Usually persist, when I try to ping/reach from 5GHz to 2.4GHz.
For example my laptop connected via 5GHz wifi, and I can't reach my son's tablet which connected to 2.4GHz wifi.
If I'm pinging backward, from my son's tablet to my laptop, arp table filled up, and everything's working fine...

[openwrt-bot]

Jakeler:

I tried 17.01.0-rc, 17.01.0 and 17.01.1. Now also 17.01.2, makes no difference, all have this bug.

[openwrt-bot]

jaimet:

I had/have what I think is the same bug (BT Home Hub 2B, lantiq xway, lede reboot 17.01.1) but I think I've found a work-around. This is just a "long-shot", but could you please see whether you are using "mac address over-rides" on any of your network interfaces ("macaddr" options in /etc/config/network)? If yes, could you please rem them out, reboot, and see whether this "fixes" the problem? (Yes, I understand that this is not a proper fix even if the problem stops).

(edit) No, I now think that this is not a workaround (it is probably the reboot which temporarily "fixed" the problem). Sorry for the noise...

[openwrt-bot]

Jakeler:

Additional interresting information here:
https://forum.lede-project.org/t/clients-in-same-wlan-cant-reach-each-other/2501/22?u=jake

For everyone the experiences this, please check the hairpin mode, is it 0?
It is 0 on my device and setting it directly to 1 (temporarily) fixes the problem.

[openwrt-bot]

pietia:

I have same problem however after 1 month of running, /etc/init.d/network restart fixed this , simply arp wasnt working and hosts couldn't communicate with each other in the same Wireless lan and I had to restart network to fix the arp communication.

[openwrt-bot]

zeroping:

I have also experienced this issue on 17.01.4. I noticed it with an uptime around 70 days. All of the devices in my bridge had hairpin mode already set to '1', and I manually set the last one to '1' with no effect. '/etc/init.d/network restart' fixed it, however. I'll have to wait for it to happen again to try to diagnose further.

[openwrt-bot]

K2DLS:

After upgrading my WRT1900AC to LEDE 17.01.4, I noticed that Chromecast had stopped working. In searching for an answer I found this thread:

https://forum.lede-project.org/t/odhcpd-as-ipv4-dhcp-w-unbound-dns/12630/4

Even though I have not defined AP isolation, the contents of /tmp/run/hostapd-phy0.conf contains ap_isolate=1 in the definition for my 2.4 GHz interface.

ap_isolate=1 is also present in /tmp/run/hostapd-phy1.conf which is the definition for my 5 GHz interface.

As a workaround to the problem, I changed /sys/devices/virtual/net/br-lan/brif/wlan0/brport/hairpin_mode from 1 to 0. Then, Chromecast began to work.

This appears to be a widespread issue which merits higher prioritization.

[openwrt-bot]

wutr:

Same for me on LEDE Reboot 17.01.4 on TP-Link Archer C5 v1.20

I have a 2.4GHz, 5GHz and Ethernet network and devices connected to each. When running "wifi" everything works, but after a yet-to-be-determined time the following is the case:

pinging that works:

2.4wlan -> lan
5.0wlan -> lan
5.0wlan -> 5.0wlan
2.4wlan -> 5.0wlan
lan > wlan

pinging that doesn't work:

2.4wlan > 2.4wlan
5.0wlan > 2.4wlan

[openwrt-bot]

JonFo:

Confirm that similar happens on 17.01.4 on a TP-Link Archer C7v2

Most noticeable is loss of mDNS broadcast traffic from LAN <--> WLAN and from WLAN <--> WLAN

Time span to failure is 1 to 2 days in my case

[openwrt-bot]

RadianM:

Just installed LEDE Reboot 17.01.4 on Linksys WRT1900ACS and get the same problem of no communication possible between devices connected via the two radios after a day or so of reboot. This is with the supplied default configurations.

[openwrt-bot]

wutr:

I don't know if there have been any updates, I certainly haven't manually updated anything, but after running wifi multiple times over the span of a few weeks (I didn't make any records of it) I haven't encountered the issue for at least three weeks, possibly longer. I have not rebooted the device either. Has anyone else had any problems with this recently?

[openwrt-bot]

bhrt:

I don know if it will help but I had similar issue, and what worked for me was już removing '.' comma character from wireless interface name.

I could not access wifi clients connected to 2.4 interface. on 5Gz everything was working fine.

Changing ifname to wifi_2-4ghz instead of wifi_2.4ghz solved the issue.

TP-Link Archer C5 v1 -> OpenWrt 18.06-SNAPSHOT r7301-55bbd8293c

[openwrt-bot]

nlcampos:

Hi guys!

I can confirm this bug and the solution from Lukas.
In my case, I had the 4 wifi interfaces and they was named wlan0 (5Ghz),
wlan1 (2.4Ghz), wlan1-1 (2.4GHz) and wlan1-2 (2.4GHz) and my router has
the same problem: users from interface wlan1-1, for example, couldn't see
it other.
After I had changed wlan1-1 and wlan1-2 to wlan1.1 and wlan1.2, respectively,
it began to work. All users can see it other.
So, imho, the bug is in the fact the interface has "-" and the OpenWRT
isn't prepared to read it. However, it's OpenWRT's default to put "-"
when you create more that 2 interfaces.
Btw, my router is an Archer C60 using OpenWrt 18.06.1 r7258-5eb055306f
Please, developers, fix it.

Kind regards,

Nelson Campos, PMP

[openwrt-bot]

willowen100:

I can confirm that naming the radio interface especially on the 2.4GHz (radio 0 / WLAN 0) does isolate devices from communcating with one another whilst connected to the same AP.

This was tested on a Linksys WRT1900AC with OpenWrt SNAPSHOT r8459-3a6bddd7f7 / LuCI Master (git-18.318.72220-6bc04b6) | Kernel 4.14.81

[openwrt-bot]

JasMan78:

I have a similar issue with my TP-Link AC1750 and OpenWRT 18.06.1 r7258-5eb055306f.

Sometimes I can't reach my wifi radio from other clients in the same VLAN, regardless if they are connected by wifi or cable.
Other clients in the same wifi are reachable. But they regularly disconnect and reconnect to the wifi, like my mobile phone. I guess the issue only occures at clients, which are permanently connected to the wifi.

I did an tcpdump on the wifi interface and saw the ARP requests from the clients to the radio, but no answers from the radio back.

The radio itself send regulary a SSDP discovery paket and all clients, which answering this packets, are able to communicate to the radio again.

Also the radio can play Internet streams. When I start it, it sends out an ARP request for the gateway. The gateway answers and right after the answer, I can ping the radio from the gateway address again (because the L2 devices between the radio and the gateway know the route to the radio again).

To solve the problem I have to deauthenticate the radio from the wifi, or restart the router. A restart of the radio doesn't help.

The default name of my interfaces was wlan0 and wlan1 (new in current version?). So there's no . or - in the name. Therefore I guess (or better I hope) renaming the interface resolves the issue. I did this yesterday and have to wait now if it happens again.

[openwrt-bot]

JasMan78:

FYI: The renaming of the interfaces did not solved the issue for me.

[openwrt-bot]

JasMan78:

OpenWRT 18.06.4 made it even worser.
The issue appears now every day.

[openwrt-bot]

JasMan78:

Update: Since I've reseted my router to factory defaults and configured it new without using a backup, the issue did never appeared again.

[openwrt-bot]

UBWH:

Bug still in V19.07.4

Details:
https://forum.openwrt.org/t/bug-report-802-11s-mesh-v19-07-4/78524

This is a show stopper for 802.11s mesh-points

[openwrt-bot]

cpatulea:

+1 seeing this on OpenWrt 19.07.2 on a Buffalo WZR-600DHP.

With default settings ("Isolate clients" unchecked), clients cannot 'ping' each other and Chromecast (which relies on multicast) is very unreliable. The interface and hostapd parameters are:

# grep isolate /var/run/hostapd-phy0.conf
ap_isolate=1
# ( cd /sys/devices/virtual/net/br-lan/lower_wlan0/brport; g
rep -H . multicast_to_unicast hairpin_mode; )
multicast_to_unicast:1
hairpin_mode:1

For a simple ping test, using a third device as 802.11 sniffer, we can see ARP broadcast sent by client1 (.10):
3937 0.022 IntelCor_e5:dd:5a Broadcast ARP 130 Who has 192.168.1.36? Tell 192.168.1.10

these are lost, there is no reply (.36), I think due to 802.11 powersave (?). Client 2 is probably in powersave, as most 802.11 clients usually are, and only AP knows the right moment to transmit frames (just after beacon frame, or PS-Poll). Client 1 always gets unlucky and sends when C2 is sleeping.

When setting the following settings:
config interface 'lan'
option multicast_to_unicast '0'
config wifi-iface 'default_radio0'
option isolate '0'

then the interface and hostapd parameters are:
# grep isolate /var/run/hostapd-phy0.conf

# ( cd /sys/devices/virtual/net/br-lan/lower_wlan0/brport; g
rep -H . multicast_to_unicast hairpin_mode; )
multicast_to_unicast:0
hairpin_mode:0

now the clients can reach each other, by AP re-transmit the frames (from looking at 802.11 "Transmitter address" and "Receiver address" fields):

[c1->ap] 14378 2.156 192.168.1.10 192.168.1.36 62 ICMP 186 Echo (ping) request id=0x0ca6, seq=1/256, ttl=62 (no response found!)
[ap->c2] 14380 0.000 192.168.1.10 192.168.1.36 62 ICMP 186 Echo (ping) request id=0x0ca6, seq=1/256, ttl=62 (reply in 14382)
[c2->ap] 14382 0.001 192.168.1.36 192.168.1.10 64 ICMP 186 Echo (ping) reply id=0x0ca6, seq=1/256, ttl=64 (request in 14380)
[ap->c1] 14384 0.000 192.168.1.36 192.168.1.10 64 ICMP 186 Echo (ping) reply id=0x0ca6, seq=1/256, ttl=64

I think AP re-transmit is necessary for reliable transmission, since only AP is aware of client powersave state, can buffer frames, etc.

The fact that re-transmit does not work with default settings ("Isolate clients" disabled) seems like a significant bug to me, wish the bug "Priority" would be increased.

[openwrt-bot]

dis7ant:

I think I'm just here to suggest we raise the priority of this bug to something more than "meh."

This breaks my project, so anything I can do to help...

Edit:
here's what's going on https://forum.openwrt.org/t/bug-report-802-11s-mesh-v19-07-4/78524

[openwrt-bot]

Neustradamus:

Have you progressed on this bug?

[openwrt-bot]

captn3m0:

Facing this on ASUS Rt-AC58U running OpenWrt 21.02.1 r16325-88151b8303.

I can ping my Printer (connected to radio0, 2.4Ghz) from the router itself, but can't ping it from a device connected to (radio1, 5GHz)

Client isolation is disabled on both networks, and both networks are attached to lan

[NBSOD]

Same problem on openwrt 21.02 SNAPSHOT ,i have to add another ssid to let my clients can get connection
wireless config no isolate
networt-interface no isolate
hairpin is 1

[badfish]

Is this caused by FS#3290 (issue 8159) ?

[kyogithub]

I'm running SNAPSHOT / LuCI Master 24.304.46082 and still show the same issue when fresh install, WLAN-WLAN and LAN-WLAN doesn't do ping, activating multicast to unicast in WLAN APs solve the issue...