I will check this issue later.

from mwlwifi.

root@LEDE:/tmp/run# cat 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
channel=149

ieee80211n=1
ht_coex=0
ht_capab=[HT40+][LDPC][SHORT-GI-20][SHORT-GI-40][MAX-AMSDU-7935][DSSS_CCK-40]
vht_oper_chwidth=1
vht_oper_centr_freq_seg0_idx=155
ieee80211ac=1
vht_capab=[RXLDPC][SHORT-GI-80][SHORT-GI-160][SU-BEAMFORMER][SU-BEAMFORMEE][RX-ANTENNA-PATTERN][TX-ANTENNA-PATTERN][RX-STBC-1][VHT160][MAX-MPDU-11454][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_group_rekey=60

wpa_passphrase=12345678
auth_algs=1
wpa=2
wpa_pairwise=CCMP
ssid=LEDE-8964-5g
bridge=br-lan
wpa_key_mgmt=WPA-PSK
okc=0
disable_pmksa_caching=1
bssid=00:50:43:22:88:8a

from mwlwifi.

Using LEDE 17.01.2 and latest mwlwifi driver, I cannot reproduce the issue reported on my previous comment.

from mwlwifi.

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

from mwlwifi.

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.

from mwlwifi.

I've seen this as well on 10.3.0.3

from mwlwifi.

I'm having the same issue using a recent Lede build.
Any updates or a workaround?

from mwlwifi.

Any updates? This only occurs on 2.4GHZ for me.
For example I have an iPad and if I connect it to the wrt1900ac on the 5ghz I can use another wifi client and ping it (which correctly does an arp and gets the mac address). However if I connect the same iPad to the same router only to the 2.4GHZ radio ping fails as arp requests are filtered out.

from mwlwifi.

@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.
Any debug info I can provide when this occurs?

Thanks.

from mwlwifi.

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.

from mwlwifi.

Same here:

• WRT3200ACM
• LEDE 17.01.1 + kmod-mwlwifi_4.4.61+10.3.4.0-20170421 @ bd62e37
• Wireless client up and running, it even runs a watchdog daemon that pings the router periodically.
• PING from router works as expected, ARP tables at router show both wireless and wired client.
• PING from wired client fails with "Destination Host Unreachable", and ARP tables at wired client show wireless client as "incomplete".
• After running PING at wired client for a while, it starts working, and ARP tables show wireless client.

from mwlwifi.

I will check it later. Thanks.

from mwlwifi.

I have a similar issue where Bonjour services disappear off the network:

• WRT1900ACS
• davidc502's May 12th build
• kmod-mwlwifi: 4.9.20+10.3.4.0-20170512-1
• Devices will appear on network for 10 to 20 hours, then disappear for approximately 30 minutes.

from mwlwifi.

Same problem here

• WRT1900AC v1
• Lede 17.01.1

• WRT3200ACM
• Lede 17.01.1
• mwlwifi driver version 10.3.4.0-20170512

AirPrint printers and other bonjour services (or avahi) disappears after about 24 hours

from mwlwifi.

Same problem. Running Lede 17.01.2on WRT3200ACM.
I wanted to try modifying a few settings to test a hunch, but not sure how.

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?
In a similar fashion, how would I modify the Inactivity Timeout Options? The devices sit idle most of the time, expect they resych time with NTP once an hour. I wanted to see if extending the inactivity timeout to be > 1hr helps keep them online longer.

Thanks

from mwlwifi.

• Lede 17.01.2
• WRT3200ACM
• driver version 10.3.4.0-20170711

same issues, after a short time printers and avahi services disappears

from mwlwifi.

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

from mwlwifi.

arping is working:

root@LEDE:/etc# iw wlan0 station dump
Station 5c:f9:38:96:62:e0 (on wlan0)
inactive time: 51720 ms
rx bytes: 26966
rx packets: 290
tx bytes: 16856
tx packets: 106
tx retries: 0
tx failed: 0
rx drop misc: 0
signal: -15 dBm
signal avg: -17 dBm
tx bitrate: 866.7 MBit/s VHT-MCS 9 80MHz short GI VHT-NSS 2
rx bitrate: 48.0 MBit/s
authorized: yes
authenticated: yes
associated: yes
preamble: long
WMM/WME: yes
MFP: no
TDLS peer: no
DTIM period: 2
beacon interval:100
short slot time:yes
connected time: 155 seconds

root@LEDE:/etc# arping -I br-lan 10.19.120.88
ARPING to 10.19.120.88 from 10.19.120.254 via br-lan
Unicast reply from 10.19.120.88 [5c:f9:38:96:62:e0] 0.954ms
Unicast reply from 10.19.120.88 [5c:f9:38:96:62:e0] 154.771ms
Unicast reply from 10.19.120.88 [5c:f9:38:96:62:e0] 76.730ms
Unicast reply from 10.19.120.88 [5c:f9:38:96:62:e0] 305.377ms
Unicast reply from 10.19.120.88 [5c:f9:38:96:62:e0] 83.636ms
Unicast reply from 10.19.120.88 [5c:f9:38:96:62:e0] 0.861ms
Unicast reply from 10.19.120.88 [5c:f9:38:96:62:e0] 90.473ms
Unicast reply from 10.19.120.88 [5c:f9:38:96:62:e0] 195.456ms
Unicast reply from 10.19.120.88 [5c:f9:38:96:62:e0] 220.370ms
Unicast reply from 10.19.120.88 [5c:f9:38:96:62:e0] 244.445ms
Unicast reply from 10.19.120.88 [5c:f9:38:96:62:e0] 267.964ms
Unicast reply from 10.19.120.88 [5c:f9:38:96:62:e0] 291.740ms

from mwlwifi.

So I have no idea what should I check?

from mwlwifi.

It also works for WRT3200ACM, I just replaced with 88W8964 module.

root@LEDE:/# iw wlan0 station dump
Station 5c:f9:38:96:62:e0 (on wlan0)
inactive time: 4294720606 ms
rx bytes: 4013
rx packets: 32
tx bytes: 1938
tx packets: 14
tx retries: 0
tx failed: 0
rx drop misc: 2
signal: -38 dBm
signal avg: -36 dBm
tx bitrate: 702.0 MBit/s VHT-MCS 8 80MHz VHT-NSS 2
rx bitrate: 780.0 MBit/s VHT-MCS 9 80MHz VHT-NSS 2
authorized: yes
authenticated: yes
associated: yes
preamble: long
WMM/WME: yes
MFP: no
TDLS peer: no
DTIM period: 2
beacon interval:100
short slot time:yes
connected time: 3 seconds
root@LEDE:/# arping -I br-lan 10.19.120.88
ARPING to 10.19.120.88 from 10.19.120.254 via br-lan
Unicast reply from 10.19.120.88 [5c:f9:38:96:62:e0] 1.051ms
Unicast reply from 10.19.120.88 [5c:f9:38:96:62:e0] 2.310ms
Unicast reply from 10.19.120.88 [5c:f9:38:96:62:e0] 467.602ms
Unicast reply from 10.19.120.88 [5c:f9:38:96:62:e0] 2.043ms
Unicast reply from 10.19.120.88 [5c:f9:38:96:62:e0] 106.571ms
Unicast reply from 10.19.120.88 [5c:f9:38:96:62:e0] 129.676ms
Unicast reply from 10.19.120.88 [5c:f9:38:96:62:e0] 154.844ms
Unicast reply from 10.19.120.88 [5c:f9:38:96:62:e0] 184.713ms
Unicast reply from 10.19.120.88 [5c:f9:38:96:62:e0] 204.452ms

from mwlwifi.

Change wpa_group_rekey to 60 seconds, arping still works:

root@LEDE:/tmp/run# uptime
03:51:44 up 9 min, load average: 0.00, 0.03, 0.00
root@LEDE:/tmp/run# arping -I br-lan 10.19.120.88
ARPING to 10.19.120.88 from 10.19.120.254 via br-lan
Unicast reply from 10.19.120.88 [5c:f9:38:96:62:e0] 5.347ms
Unicast reply from 10.19.120.88 [5c:f9:38:96:62:e0] 233.748ms
Unicast reply from 10.19.120.88 [5c:f9:38:96:62:e0] 258.352ms
^CSent 5 probe(s) (2 broadcast(s))
Received 3 reply (0 request(s), 0 broadcast(s))
root@LEDE:/tmp/run# uptime
03:52:26 up 10 min, load average: 0.00, 0.03, 0.00
root@LEDE:/tmp/run# arping -I br-lan 10.19.120.88
ARPING to 10.19.120.88 from 10.19.120.254 via br-lan
Unicast reply from 10.19.120.88 [5c:f9:38:96:62:e0] 86.464ms
Unicast reply from 10.19.120.88 [5c:f9:38:96:62:e0] 29.770ms
Unicast reply from 10.19.120.88 [5c:f9:38:96:62:e0] 129.485ms
^CSent 3 probe(s) (1 broadcast(s))
Received 3 reply (0 request(s), 0 broadcast(s))
root@LEDE:/tmp/run# uptime
03:53:47 up 11 min, load average: 0.00, 0.02, 0.00
root@LEDE:/tmp/run# arping -I br-lan 10.19.120.88
ARPING to 10.19.120.88 from 10.19.120.254 via br-lan
Unicast reply from 10.19.120.88 [5c:f9:38:96:62:e0] 74.121ms
Unicast reply from 10.19.120.88 [5c:f9:38:96:62:e0] 302.424ms
Unicast reply from 10.19.120.88 [5c:f9:38:96:62:e0] 121.737ms
^CSent 3 probe(s) (1 broadcast(s))
Received 3 reply (0 request(s), 0 broadcast(s))

from mwlwifi.

LEDE image I used to do arping test (for WRT3200ACM with latest mwlwifi dirver):
factory: https://drive.google.com/open?id=0B3qLWtcWB9EdcC1PWjYxeTJHUUU
upgrade: https://drive.google.com/open?id=0B3qLWtcWB9EdRmdUU3NJU3IzY2s

root@LEDE:/# cat /sys/kernel/debug/ieee80211/phy0/mwlwifi/info

driver name: mwlwifi
chip type: 88W8964
hw version: 7
driver version: 10.3.4.0-20170713
firmware version: 0x09030007
power table loaded from dts: no
firmware region code: 0x10
mac address: 00:50:43:22:88:8a
2g: disable
5g: enable
antenna: 4 4
irq number: 44
ap macid support: 0000ffff
sta macid support: 00010000
macid used: 00000007
radio: enable
iobase0: f0d80000
iobase1: f1000000
tx limit: 1024
rx limit: 16384

from 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

from mwlwifi.

I don't know what your problem is. However, mwlwifi has no problem to pass broadcast data to client.

from mwlwifi.

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.

from mwlwifi.

The issue is not immediate, can you try to control if pass the broadcast traffic after 24 hours?

from mwlwifi.

Can you create another issue? I can use 88W8964 to do test.

from mwlwifi.

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.

from mwlwifi.

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!

from mwlwifi.

Thanks for your information.

from mwlwifi.

It is good to know that. Thanks.

from mwlwifi.