Wireless clients stop receiving DHCP responses after some time

[Alexander-r]

Starting from commit af210f0 I had problems with broadcast traffic. After some time if a new wireless client connects it will not receive an IP address. In the logs on the router I see DHCPDISCOVER request and the attempt to send DHCPOFFER reply but it seems the client does not receive it. It just sends more requests. The clients already connected to the network continue to work fine. Wired clients continue to work fine too.

There are no errors in system and kernel log that might help identify why this starts happening. This problem occurs on both 2.4GHz and 5GHz networks. And it starts at random intervals after reboot. Router may work fine for a day or it may stop sending broadcast traffic after an hour of uptime. I can reproduce this problem on two android devices, notebook with Intel wireless 7265 and another router acting as client based on Atheros QCA9880. So it’s not just a single device affected.

I’ve tried the latest version of the driver after that but it also has this problem. I even tried compiling the latest lede snapshot with this driver but that did not help. The strangest this is that when I flashed clean lede 17.01.4 and tried it without updated driver I also had this problem. I also tried using odhcpd instead of dnsmasq. In all the tests I used the same configuration. And I have not changed any settings before noticing the problem.

My configuration files:

wireless

config wifi-device 'radio0'
    option type 'mac80211'
    option channel '36'
    option hwmode '11a'
    option path 'soc/soc:pcie-controller/pci0000:00/0000:00:01.0/0000:01:00.0'
    option htmode 'VHT80'
    option txpower '23'
    option country 'US'

config wifi-iface 'default_radio0'
    option device 'radio0'
    option network 'lan'
    option mode 'ap'
    option encryption 'psk2'
    option key '1234567890'
    option ssid 'WiFi_5'

config wifi-device 'radio1'
    option type 'mac80211'
    option channel '11'
    option hwmode '11g'
    option path 'soc/soc:pcie-controller/pci0000:00/0000:00:02.0/0000:02:00.0'
    option htmode 'HT40'
    option txpower '30'
    option country 'US'

config wifi-iface 'default_radio1'
    option device 'radio1'
    option network 'lan'
    option mode 'ap'
    option encryption 'psk2'
    option key '1234567890'
    option ssid 'WiFi_2'

dhcp

config dnsmasq
    option domainneeded '1'
    option boguspriv '1'
    option filterwin2k '0'
    option localise_queries '1'
    option rebind_protection '1'
    option rebind_localhost '1'
    option local '/lan/'
    option domain 'lan'
    option expandhosts '1'
    option nonegcache '0'
    option authoritative '1'
    option readethers '1'
    option leasefile '/tmp/dhcp.leases'
    option resolvfile '/tmp/resolv.conf.auto'
    option localservice '1'

config dhcp 'lan'
    option interface 'lan'
    option start '100'
    option limit '150'
    option leasetime '12h'
    option dhcpv6 'server'
    option ra 'server'
    option ra_management '1'

config dhcp 'wan'
    option interface 'wan'
    option ignore '1'

config odhcpd 'odhcpd'
    option maindhcp '0'
    option leasefile '/tmp/hosts/odhcpd'
    option leasetrigger '/usr/sbin/odhcpd-update'

network

config interface 'loopback'
    option ifname 'lo'
    option proto 'static'
    option ipaddr '127.0.0.1'
    option netmask '255.0.0.0'

config globals 'globals'
    option ula_prefix 'fd9c:6fdc:99cb::/48'

config interface 'lan'
    option type 'bridge'
    option ifname 'eth0'
    option proto 'static'
    option netmask '255.255.255.0'
    option ip6assign '60'
    option ipaddr '192.168.0.1'

config interface 'wan'
    option ifname 'eth1'
    option proto 'dhcp'

config interface 'wan6'
    option ifname 'eth1'
    option proto 'dhcpv6'

config switch
    option name 'switch0'
    option reset '1'
    option enable_vlan '1'

config switch_vlan
    option device 'switch0'
    option vlan '1'
    option ports '0 1 2 3 5'

config switch_vlan
    option device 'switch0'
    option vlan '2'
    option ports '4 6'

[yuhhaurlin]

Does anyone else encounter the same problem? Currently other users posted here does not have the same issue.

[eduperez]

Not sure if related to the problem reported here, but I have a similar problem:

• Main router: WRT3200ACM running LEDE 17.01.4 plus updated (commit 843d00c) mwlwifi drivers.
• Wireless extender: WDR4300 running LEDE 17.01.4
• Wired devices connected to both the main router and the wireless extender

Main router can reach the wireless extender, and can reach wired devices connected to the wireless extender. However, wired devices connected to the main router sometimes cannot reach either the wireless extender or the wired devices connected to the wireless extender.

When this happens, ARP tables on the router look normal, but ARP tables on the wired client connected to the main router show "incomplete" for both the wireless extender and the wired client connected to the wireless extender.

If ARP traffic is being dropped, then everything else is going to stop working.

[yuhhaurlin]

@eduperez This only happened with new firmware?

[yuhhaurlin]

Please let me know if this is only happened with new firmware. If yes, I can check the way to handle broadcast data on firmware for power save mode.

[eduperez]

@yuhhaurlin I experienced this a long time ago (see my comment at issue #36 ). Then it stopped happening, and I forgot about the issue.

I have been testing the set-up mentioned above for months, but using "relayd" instead of WDS", without any trouble. Then I began using WDS as soon as it was available for STA mode, and noticed the issue right from the beginning.

This could be related to the latest firmware, but it could also be related to WDS.

[yuhhaurlin]

If you use relayd on the new driver, will you encounter this problem? I will do some tests by myself next week. Thanks.

[Alexander-r]

@yuhhaurlin I first encountered it on version af210f0. It also happens on version 843d00cd9c134629b9dad7162831ec5f136399b3. It takes from about a couple of hours to a day. So far I have not found any particular steps that would cause this problem to happen immediately. It just happens randomly.

What else can I do to help determine what might cause the problem?

[yuhhaurlin]

@eduperez Your problem could be the root cause for this issue here.

[yuhhaurlin]

@Alexander-r Can you only replace firmware back to 9.3.0.8 to see if you will encounter this problem.

[Alexander-r]

@yuhhaurlin Will test it with that firmware.

[yuhhaurlin]

@Alexander-r Only roll back firmware of 88W8964 to 9.3.0.8. Thanks.

[Alexander-r]

@yuhhaurlin Ok will just replace 88W8964.bin with this one https://github.com/kaloz/mwlwifi/blob/e119077b68d64e368cb9cc46bd364308db4289dc/bin/firmware/88W8964.bin on my current setup with 843d00c driver.

[ad019]

@yuhhaurlin even after 6 hrs, the printer is working fine on the test network.

[yuhhaurlin]

@ad019 Thanks. Can you create another issue to track this wireless printer issue? After this one is fixed, you can test the updated driver. If problem is still there, I will try to fix it.

[MrReSc]

@Alexander-r @yuhhaurlin As I mentioned in the beginning of this disscousion, I'm facing the same problem. I already tested the 9.3.0.8 and didn't fix the issue! I changed the client to dynamic IP and add a the client to the static lease. But this worked either.

@yuhhaurlin I'm never facing this n the LAN, so it looks like a Wifi issue!

[yuhhaurlin]

@MrReSc In your case, client has no problem to work with router, but just can't ping to each other. I wonder this is only for special client or all clients has this kind of problem.

[MrReSc]

As I mentioned as well, it's not just the ping. I'm not able to controll my media players with the remote app. (Client to Client)

[yuhhaurlin]

All clients or special clients?

[yuhhaurlin]

If the problem only happened on special clients, can you cat /sys/kernel/debug/ieee80211/phy0 or phy1/mwlwifi/sta to see if TDLS is on for these clients?

[MrReSc]

These are very common clients. Intel NUC with Intel Wlan 7265.

[MrReSc]

But I may have to correct myself. The workaround with the static lease looks to work. So, maybe @Alexander-r can test it as well.

[yuhhaurlin]

I am confused. Maybe you can wait for this issue to be fixed, then you can test on the updated driver to check if your problem is gone.

[leifliddy]

I'm using firmware version 9.3.0.8 of 88W8964, but am continuing a experience a variety of issues. I'm using the linksys3200acm as a secondary router (connected to primary router via ethernet over coaxial adapter). I have multiple devices connected to radio0 (5ghz) on on the linkys3200acm. However, I can't even ping any of these devices from the linksys3200acm router itself, or from any device connected to it. What's odd, is that I can ping all devices connected to radio0 on the linksys3200acm from my primary router or from devices connected to my primary router. I'm struggling to understand how that's even possible. If I reboot the linksys router everything will work for a short time before this issue occurs again. One of the devices connected to radio0 on the linksys3200acm is a chromecast. It's basically unusable at the moment, unless I keep rebooting my router. Going to revert back to the stock firmware for the moment and will revisit this in a couple of months.

[ghost]

I wanted to chime in and confirm using the latest commit and firmware in an environment that 2.4g is overcrowded that most of my devices use 2.4 (aside from phones and laptops/notebooks), I have had no issues with on either band up close or far away and devices that lost connection before rarely happen now on Rango WRT3200ACM.

On Dec 16, 2017 4:45 PM, "yuhhaurlin" notifications@github.com wrote:

I'm using firmware version 9.3.0.8 of 88W8964, but am continuing a experience a variety of issues. I'm using the linksys3200acm as a secondary router (connected to primary router via ethernet over coaxial adapter). I have multiple devices connected to radio0 (5ghz) on on the linkys3200acm. However, I can't even ping any of these devices from the linksys3200acm router itself, or from any device connected to it. What's odd, is that I can ping all of these devices from my primary router (or from devices connected to my primary router). I'm struggling to understand how that's even possible. If I reboot the linksys router everything will work for a short time, before this issue occurs again.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/kaloz/mwlwifi/issues/243#issuecomment-352258405, or mute the thread https://github.com/notifications/unsubscribe-auth/ARIphOc_pKJOrW20DY0tglfp2-TV8n8Qks5tBSE2gaJpZM4RDoj5 .

[ghost]

@leifliddy

Aside from you using a older mwlwifi driver and firmware, it looks like the problem you are seeing is caused by an issue with the way your LAN is setup on both routers not a Wi-Fi issue.

On Dec 17, 2017 8:12 AM, "leifliddy" notifications@github.com wrote:

I'm using firmware version 9.3.0.8 of 88W8964, but am continuing a experience a variety of issues. I'm using the linksys3200acm as a secondary router (connected to primary router via ethernet over coaxial adapter). I have multiple devices connected to radio0 (5ghz) on on the linkys3200acm. However, I can't even ping any of these devices from the linksys3200acm router itself, or from any device connected to it. What's odd, is that I can ping all of these devices from my primary router (or from devices connected to my primary router). I'm struggling to understand how that's even possible. If I reboot the linksys router everything will work for a short time, before this issue occurs again.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/kaloz/mwlwifi/issues/243#issuecomment-352258405, or mute the thread https://github.com/notifications/unsubscribe-auth/ARIphOc_pKJOrW20DY0tglfp2-TV8n8Qks5tBSE2gaJpZM4RDoj5 .

[leifliddy]

@rs-se what's wrong with the way my lan is setup? Notice I singled out the 5ghz radio, not the 2.4ghz radio. Everything works fine with the 2.4ghz radio. All three radios on the linksys3200acm are bridged to br-lan as per the standard configuration. **they are all tied to the same logical interface Intermittent behavior --such as I ping device X connected to radio X, that is 'resolved' via a reboot is rarely tied to a configuration issue. Please read the thread before commenting. Firmware version 9.3.0.8 seems to be the most stable. But, there are issues with every version of 88W8964.

[Alexander-r]

@yuhhaurlin It has been almost a day and so far there were no problems with 9.3.0.8 firmware. So I would say my problem is caused by something in the new firmware.

[yuhhaurlin]

Thanks. I will try to fix this problem.

[ghost]

@leifliddy

Perhaps you need to read your own post before commending, your first post mentioned issues with communication between First and Secondary router. I am sorry but I don’t work for Marvell but it doesn’t take a genius to see that there is more at work here than just WiFi.

There is a small handful of people who have had issues with newest firmware/driver, however it appears there is more people who aren’t seeing an issue but this doesn’t mean there isn’t a problem. WRT3200ACM has finally become stable on 2.4/5Ghz on my end for close and far away radio communication and nearly no devices losing connection (printers, amazon echo, and amazon readers).

Crossing fingers that any fix that comes about, doesn’t cause problems for others.

Sent from Mail for Windows 10

From: leifliddy Sent: Sunday, December 17, 2017 3:01 PM To: kaloz/mwlwifi Cc: rs-se; Mention Subject: Re: [kaloz/mwlwifi] Wireless clients stop receiving DHCP responsesafter some time (#243)

@rs-se what's wrong with the way my lan is setup? Notice I singled out the 5ghz radio, not the 2.4ghz radio. Everything works fine with the 2.4ghz radio. All three radios on the links3200acm are bridged to br-lan as per the standard configuration. **they are all tied to the same logical interface Intermittent behavior --such as I ping device X connected to radio X, that is 'resolved' via a reboot is rarely tied to a configuration issue. Please read the thread before commenting. Firmware version 9.3.0.8 seems to be the most stable. But, there are issues with every version of 88W8964. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[leifliddy]

@rs-se The issue also occurs if I'm just using the one router. Just stating that 'oh, your configuration is messed up' doesn't really provide anything in terms of diagnosing the issue, nor does it provide any sort of solution. Hell, you haven't even defined what you think is wrong with the configuration. Please let me know when you have something useful to contribute.

[aaron1959]

@leifliddy Just go ahead and post the logs documenting the refusal of the WRT3200ACM to allow ping to pass through or whatever the exact goal it is that you're trying to achieve. With a log someone may be able to point you in the right direction. But someone told you they don't think it's a mwlwifi issue and I do think they're correct. No need to be upset just document the failure, and post the log. Oh and since you can create the problem with just one wrt3200acm, maybe it will be easier to pin down your issue if you don't involve the other router yet and just focus on fixing the single router you say you can make the problem on.

[eduperez]

@yuhhaurlin Where exactly are we supposed to check for TDLS? I can see the debug folder for each station, but I do not know what to look for there. Thanks!

[yuhhaurlin]

Sorry. Please use "iw wlan0/wlan1 station dump".

root@LEDE:/# iw wlan0 station dump Station 5c:f9:38:96:62:e0 (on wlan0) inactive time: 146130 ms rx bytes: 14192 rx packets: 79 tx bytes: 2503 tx packets: 22 tx retries: 0 tx failed: 0 rx drop misc: 3 signal: 0 dBm signal avg: -38 dBm tx bitrate: 866.7 MBit/s VHT-MCS 9 80MHz short GI VHT-NSS 2 rx bitrate: 866.7 MBit/s VHT-MCS 9 80MHz short GI 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: 470 seconds

[eduperez]

Checked: no, none of the stations connected to the main router have TDLS active. I am now going back to latest firmware and driver but use relayd instead of WDS, and see if the issue still happens; it did not happen with previous versions and relayd. Will inform later.

[eduperez]

After reconfiguring the wireless extender to use relayd instead of WDS, wired clients connected to it can no longer get an IP address: I can see and endless conversation of DHCPDISCOVER / DHCPOFFER but no DHCPACK in the logs from main router. Perhaps I screwed something in the configuration, will have to check it thoroughly later.

[ghost]

I would like to extend an apology, I have not noticed any WiFi devices loose connection as of yet however I have just noticed similar issues with Bonjour service for printers not functioning properly on newest mwlwifi version.

TDLS also not turned on for clients.

Sent from Mail for Windows 10

From: leifliddy Sent: Sunday, December 17, 2017 4:21 PM To: kaloz/mwlwifi Cc: rs-se; Mention Subject: Re: [kaloz/mwlwifi] Wireless clients stop receiving DHCP responsesafter some time (#243)

@rs-se The issue also occurs if I'm just using the one router. Just stating that 'oh, your configuration is messed up' doesn't really provide anything in terms of diagnosing the issue, nor does it provide any sort or solution. Hell, you haven't even defined what you think is wrong with the configuration. Please let me know when you have something useful to contribute. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[yuhhaurlin]

@Alexander-r Can you help me to do one more test? Please use open mode to test latest firmware to see if you will encounter problem or not?

[Chadster766]

I'm testing the latest mwlwifi firmware binary and driver code with McDebian. Its working well so far. I did observe that it seems to be a little more sensitive to radio interference.

[eduperez]

I just rebooted the main router, and then everything began working again (using relayd), so it looks like the new firmware / driver is not the problem... I will go back to WDS and try again.

[Alexander-r]

@yuhhaurlin Will test 9.3.2.2 firmware with open network without encryption. Will tell the results tomorrow.

[Alexander-r]

@yuhhaurlin I've just encountered the problem with networks set to open mode.

[yuhhaurlin]

Thanks.

[ratsputin]

@yuhhaurlin Going back to the issue I'm seeing that seems to share some similarities to what's being described here, much like @Chadster766 comment above, I'm starting to be suspicious that my issue has something to do with long-duration external interference and the WRT's ability to deal with it.

If you'll recall, I have a Honeywell thermostat (RTH9580WF) that seems to be the most sensitive to this issue. Watching logread, I see it disconnect and reconnect randomly and successfully over the course of the day, presumably due to some external but intermittent interference. This is on Channel 11 at 1,000mW, but I've seen similar behaviors on channels 1 and 6 as well.

If, however, the interference continues for an extended period of time, the router will no longer accept connections from it, even once it clears. The way I can tell the interference is present is by attempting to connect from my iPhone and I'll receive an "Invalid Password". Trying repeatedly will eventually be successful.

To restore service, I've found the easiest route is to do a "wifi up".

So, in summary:

• I have an apparent source of intermittent interference on the 2.4GHz band
• While it is present, my Honeywell thermostat will disconnect. My iPhone will also be unable to connect, giving an "Invalid Password" error.
• If the duration of the interference is short, everything seems to recover successfully
• If the duration of the interference is long, most things seem to recover, but my Honeywell thermostat will not, requiring a "wifi up" or a "Scan" from LEDE

Hopefully, this provides some insight into what I'm seeing.

[ratsputin]

I did find a bit more information on this thermostat from the FCC certification. It's based on the USI WM-N-BM-09 "WIC-ED" wireless SiP module. This uses the Broadcom BCM43362 single-chip radio. I don't know if there are any known issues with this chip, but I figured I'd provide a bit more information in case it sheds some light on this issue.

[spamtree]

@kubrickfr Thanks for the tip - dhclient got an ipv4 address. I was using a static address until this gets fixed. One other note ivp6 was still working fine, but could not get an ipv4 address until I used dhclient instead of NetWorkManager. This is with the latest driver.

driver name: mwlwifi chip type: 88W8964 hw version: 7 driver version: 10.3.4.0-20171129 firmware version: 0x09030202

Linux laptop with Atheros AR9462 Wireless network adapter.

[robisonjoel]

I have to add to what @Chadster766 and @ratsputin are experiencing - and I think the argument presented by Chadster766 is is compelling. I run a 3200ACM at my fathers place in a new housing development, and it is VERY WiFi saturated - 50+ networks come up with a scan, scattered across 2.4/5G bands.

Oddly, My dad has the same model Honeywell Thermostat. We have been trying to track this down for months now (I started with LEDE LEDE 17.01.2), now using DavidC502's latest with 10.3.4.0-20171214 driver now. My dad would notice most when his Amazon Echo and Echo Dot would start saying they could not connect

I have been running the same LEDE builds as my dad (on a 1900ACS v2 and a 1200AC) without issue, but I live in the country and my WiFi networks are the only ones on any scan as the neighbors are miles away

[robisonjoel]

@yuhhaurlin I've updated the 3200ACM to the Driver you just posted 4 hours ago - can you confirm this is correct?

root@wifi:~# strings /tmp/88W8964.bin |grep -i version 8006.img version: B4.18.01 Dec 21 2017 03:35:37 Copyright (c) 2007, 2009-2015 by Cisco Systems, Inc.

[yuhhaurlin]

@robisonjoel I did not post driver. I just give a special version of firmware for Alexander-r to do test. If you did not use WDS, please stay with firmware 9.3.0.8.

[robisonjoel]

heh - yeah sorry, its 2am here - I meant firmware - s/Driver/Firmware/ :)

Thank you!

[daloki83]

@yuhhaurlin i've tested 9.3.2.2/9.3.2.1/9.3.0.8 with driver 10.3.4.0-20171214 on every FW version im getting this error. It looks like mostly 2 devices are affected (1x AVM Repeater 300e 1x Instar HD Webcam).

I don't use any special WiFi settings etc. and i will try your newly uploaded FW now...but atm i don't think its the FW.

Wifi conf: `config wifi-device 'radio0' option type 'mac80211' option country 'FR' option channel '48' option hwmode '11a' option path 'soc/soc:pcie-controller/pci0000:00/0000:00:01.0/0000:01:00.0' option htmode 'VHT160'

config wifi-iface 'default_radio0' option device 'radio0' option network 'lan' option mode 'ap' option ssid 'CR4P_2_5G' option encryption 'psk2' option key 'xxx'

config wifi-device 'radio1' option type 'mac80211' option country 'FR' option channel '8' option hwmode '11g' option path 'soc/soc:pcie-controller/pci0000:00/0000:00:02.0/0000:02:00.0' option htmode 'HT40' option noscan '1' option txpower '20'

config wifi-iface 'default_radio1' option device 'radio1' option network 'lan' option mode 'ap' option ssid 'CR4P_2_24G' option encryption 'psk2' option key 'xxx'

config wifi-device 'radio2' option type 'mac80211' option channel '36' option hwmode '11a' option path 'platform/soc/soc:internal-regs/f10d8000.sdhci/mmc_host/mmc0/mmc0:0001/mmc0:0001:1' option htmode 'VHT80'

config wifi-iface 'default_radio2' option device 'radio2' option network 'lan' option mode 'ap' option ssid 'LEDE' option encryption 'none' option disabled '1' `