OpenWrt/LEDE Project

  • Status Unconfirmed
  • Percent Complete
  • Task Type Bug Report
  • Category Base system
  • Assigned To No-one
  • Operating System All
  • Severity High
  • Priority Very Low
  • Reported Version All
  • Due in Version Undecided
  • Due Date Undecided
  • Private
Attached to Project: OpenWrt/LEDE Project
Opened by Jake - 17.04.2017

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

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

Sterling Hubbard commented on 31.05.2017 15:32

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.

Peter Nyilas commented on 06.06.2017 20:50

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

Jake commented on 15.06.2017 19:32

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.

Jaime Towns commented on 21.06.2017 09:53

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

Jake commented on 09.07.2017 22:14

Additional interresting information here:

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.

piotr commented on 13.07.2017 08:53

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.

Scott G commented on 17.03.2018 12:14

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.

K2DLS commented on 07.04.2018 12:48

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:

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.

wutr commented on 16.05.2018 17:41

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

Jonathan commented on 24.05.2018 16:22

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

RadianM commented on 28.05.2018 21:44

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.

wutr commented on 23.07.2018 16:16

I don't know if there have been any updates, I certainly haven't manually updated anything, but after running


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?

Lukas commented on 19.11.2018 22:55

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

Nelson Campos commented on 06.12.2018 00:37

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

willowen100 commented on 03.01.2019 23:59

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

JasMan78 commented on 16.09.2019 05:15

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.

JasMan78 commented on 21.10.2019 18:49

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

JasMan78 commented on 26.10.2019 11:32

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

JasMan78 commented on 22.11.2019 21:06

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


Available keyboard shortcuts


Task Details

Task Editing