New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Broadcast traffic dropped #36
Comments
Seems reproducible with r47067 and WRT1900AC V1. The effect is almost like ap_isolate - (most) wireless clients don't see each others, but connect to internet via defaultroute just fine. |
I've seen this as well on 10.3.0.3 |
I'm having the same issue using a recent Lede build. |
Any updates? This only occurs on 2.4GHZ for me. |
@yuhhaurlin any chance you can look into this? I have both the WRT1200AC and WRT1900ACv1 and I currently have to reboot them every few days as broadcast traffic is being blocked and arp packets are not sent to wifi clients. This just happened to me on both 2.4ghz and 5ghz interfaces. Thanks. |
Forgot to mention I'm using LEDE RC with the latest drivers but this is happening for more than a year with different openwrt versions and wifi versions. |
Same here:
|
I will check it later. Thanks. |
I have a similar issue where Bonjour services disappear off the network:
|
Same problem here • WRT1900AC v1 • WRT3200ACM AirPrint printers and other bonjour services (or avahi) disappears after about 24 hours |
Same problem. Running Lede 17.01.2on WRT3200ACM. Right now a group key handshake is completed every 10 minutes, I wanted to extend the period to see if this impacts drop time at all. What file/config would I need to change to change this from 10 minutes to 1 hour? Thanks |
same issues, after a short time printers and avahi services disappears |
I will check this issue later. |
We have to restart the wifi every couple of hours to be able to cast to the chromecast with WRT1900ACS and LEDE 17.0.2 |
arping is working: root@LEDE:/etc# iw wlan0 station dump root@LEDE:/etc# arping -I br-lan 10.19.120.88 |
So I have no idea what should I check? |
It also works for WRT3200ACM, I just replaced with 88W8964 module. root@LEDE:/# iw wlan0 station dump |
Change wpa_group_rekey to 60 seconds, arping still works: root@LEDE:/tmp/run# uptime |
root@LEDE:/tmp/run# cat hostapd-phy0.conf ieee80211n=1 interface=wlan0 wpa_group_rekey=60wpa_passphrase=12345678 |
LEDE image I used to do arping test (for WRT3200ACM with latest mwlwifi dirver): root@LEDE:/# cat /sys/kernel/debug/ieee80211/phy0/mwlwifi/info driver name: mwlwifi |
I have 1 WRT3200ACM and I don't experience the issue with LEDE 17.01.2, but with WRT1900ACS with LEDE 17.01.2 I have to restart the wifi every couple of hours to be able to see the chromecast again. I am using the wifi version that came with LEDE 17.01.2 |
I don't know what your problem is. However, mwlwifi has no problem to pass broadcast data to client. |
I have also tested 88W8864. I can't find problem with the driver to pass broadcast data to client. I think I will close this one. If someone can show me that mwlwifi has problem to pass broadcast data to client, I can reopen this issue and check it. |
The issue is not immediate, can you try to control if pass the broadcast traffic after 24 hours? |
Can you create another issue? I can use 88W8964 to do test. |
BTW, can you load the image I posted here to do test? When the problem happens, you can use arping to check if broadcast data is still working. |
Ok I'll try with your image and if the problem happens again I'll use arping to check if the beroadcast is working and if not I'll create a new issue. Thanks for now! |
Using LEDE 17.01.2 and latest mwlwifi driver, I cannot reproduce the issue reported on my previous comment. |
Thanks for your information. |
In my wrt3200acm using your image (uptime 3 days) the issue disappears (and even 160 MHz are now working). In my wrt1900ac The problem disappeared with lede 17.01.02 |
It is good to know that. Thanks. |
WRT1200AC, OpenWrt r46760 (10.3.0.8)
All broadcast packets are dropped on the wlan interface. Persistent behaviour, no working setup known yet. The client device can capture broadcast packets on other AP.
Easily verifiable via arping:
Packets seen with tcpdump on the AP:
The network can work more or less via ARP learning depending on the usage pattern. It's a regression with 10.3.0.8, 10.3.0.3 (-rc3) is OK.
Also reported at https://dev.openwrt.org/ticket/20437 by me.
The text was updated successfully, but these errors were encountered: