Is this a bug on Asus firmware? WAN disconnections

[shdwkeeper]

That's why I got an R7000, never had that problem since I switched.

 

[mstombs]

I'm have the same issue with a 87u. Every few days I get disconnected,ISP DHCP error. I need to reboot. Merlins latest firmware. Tried normal and aggressive modes. I thought normal fixed it but sure enough it did it again tonight.

Sep 13 19:44:15 WAN Connection: ISP's DHCP did not function properly.
Sep 13 19:44:15 stop_nat_rules: apply the redirect_rules!

I wonder if this is the same issue as that discussed in

http://www.snbforums.com/threads/wan-ip-renew-issue.26995/

If so the ping script might save you having to reboot manually.

 

[Goofie Newfie]

it seems so simple. If dhcp fails to renew, why does it not retry? isn't this very basic stuff? yet the more I google the issue, the more Asus routers seem to suffer from it. I've never seen this error on any other router I've owned. Weird.

 

[mstombs]

it seems so simple. If dhcp fails to renew, why does it not retry? isn't this very basic stuff? yet the more I google the issue, the more Asus routers seem to suffer from it. I've never seen this error on any other router I've owned. Weird.

I wonder if we need an equivalent to this?
https://lists.openwrt.org/pipermail/openwrt-devel/2014-May/025683.html

 

[shdwkeeper]

Yup. I loved the software and the 3G failover but I had to get rid of the Asus router because it kept dropping the WAN connection.

 

[YzRacer]

I would like to share a few things I experienced with my RT-AC66U that might be related to this topic.

I experienced WAN loss, but it was very seldom. It always occurred after a power outage or device reboot. When it did happen, my whole network would go down and I would be unable to connect to any device on the LAN or troubleshoot the issue. It was always resolved by powering down for 5+ minutes, disconnecting LAN connections from the router, then powering up the modem and the router and allowing a connection to establish before reconnecting my LAN items. It seemed to me that whenever devices were rebooted that some other LAN device was registering with the modem instead of the router, but the modem is most certainly plugged directly into the WAN port of the Asus.

For those on COMCAST, I have seen the SB6121 modem reboot at some timed intervals whenever my WAN is down. It can also be rebooted from the Comcast support site with "send a reset signal to my modem". My link was down for over 24 hours last year and there were several modem reboots as well as router reboots, but my link was never restored until I isolated my wired LAN during power up.

I haven't had this issue in quite some time, and finally got around to installing RMerlin's firmware. During that process I used the NVRAM backup tool to migrate to the updated firmware. Everything was working fine but when browsing through all the settings I noticed the WAN MAC was identical to another device on the LAN. I was certain I had not cloned or set a MAC previously, so I checked the NVRAM backup and did find this setting was saved from my previous configuration. I cleared the field, saved, and rebooted (hoping to restore the original router MAC and suspecting this could have been related to my WAN drops) but after reboot I found the Asus had a new MAC in the field, this time a different device on the LAN. That's when I found these:

http://www.snbforums.com/threads/wan-mac-address-random-changes.23430/
http://forums.xfinity.com/t5/Home-N...ned-MAC-address-presented-to-WAN/td-p/1902095

This is exactly the behavior I saw, but after clearing the field and checking SSH ifconfig (which showed the WAN MAC identical to the 2.4g wifi MAC) the problem seems to be resolved. This behavior made me wonder if my previous WAN drops were caused by this issue. In another thread someone just manually set the router MAC and that seems to have resolved the issue for them. I'm going to monitor for a couple of reboots and see how it goes from here with a blank MAC field in the GUI.

 

[dsjstc]

I've had (what I now assume to be) this issue periodically on Shaw Cable (BC, Canada) with an AC66U for months. Aafter upgrading to Merlin's 380.57, I started fully losing WAN after the 15 minute lease expired. THe problem persisted through multiple factory resets of the router and modem, 30-second reboots, and switches back and forth to other functional routers. I spent about four hours rebooting and trying old routers to isolate the problem, before determining that it really was the AC66U.

After going out and buying another router, I tried a 15-minute power cycle of the modem. And the bigger/newer problem is gone. I'm still getting periodic errors in the log of "WAN Connection: ISP's DHCP did not function properly", but at least it recovers gracefully now.

TLDR: Turn your modem off for 15 minutes.

 

[DT1]

Hi to all! last 6 months I faced with same problem.
RT-AC87U router linked to GPON (optical) router that is working in Bridge mode. WAN connection was dropping some time after 1 hour, some time after 2 hours. FW is Asus official and not beta. It is funny that I did not believe to my wife when she told me that "internet is not working", because when I start to check it via speed test or pinging some hosts WAN was restored already. Today I turned On Dual WAN feature with default settings of Watch Dog feature that monitors WAN 1 connectivity as I understood pinging google.com. Looks like it helped me, last 6 hours WAN is working without problem.
My ISP checked everything on their side but did not found anything. Cable between GPON and AC87U is standard CAT5 (not CAT5E and not CAT6), second WAN tuned to LAN4 (nothing is connected to it).
Hope it will help somebody.

BTW - looks like when there is no any packet sent from router to internet for some time WAN is going to sleep, while ISPs server is thinking that is On and then, when router start to send packet after wake-up it tries to obtain NEW IP and cannot connect to ISP due to conflict of 1 MAC for 2 WAN-IPs (old - obtained less then 24 hours and new - obtaining after wake-up). it is my guess only.

 

[Helogadget]

Ok, I know I am new and this is a relatively older post, but I think through trial and error I have finally discovered what is going on with this issue. Here is my set up:

ASUS RT-87U (tried on multiple firmware including Merlin's awesome newest) Cable Modem is SB6120 with Charter 100 Mbit service.

This issue became worse and worse with the "DHCP did not function properly" message. It was particularly bad at night (high bandwidth usage, wife playing Farmville, streaming media, etc) and became almost unbearable as the internet connection was continually dropping off.

I read the threads on here and tried everything people suggested (changed to Cat 6 WAN cable, tried different settings etc), still no luck. I put the old Netgear router back on and everything ran correctly. I ran Speedtest and was running around 100 Mbits give or take. Netgear ran like a champ, no dropouts.

I then put the Asus back on, reverted to an older firmware (using recovery tool) and it ran fine for a while and then started dropping out again. I ran Speedtest...wow... 134 Mbit's. Then the connection dropped with the DHCP not conf properly message. Connection came back up and I ran Speedtest again. Once again 134 Mbits and the connection dropped. I went into Qos and throttled the download bandwidth to 100 Mbit and ran Speedtest. 99.xx Mbits....no dropout. I then tried 110, 120, and 130. Every time, the connection dropped when throttled higher than 100 mbits.

I have now run Speedtest many times with the download speed throttled to the advertised bandwidth and so far, no disconnects. It appears the Asus sucks bandwidth much faster than Charter likes and it disconnects. Throttle it back to what Charter wants and it behaves.

So far so good. I will update if my theory proves wrong.

Thanks!

Edit: Since I have done this I have gotten the error today about 4 more times. It seems better, but it is still acting up. So, not a 100% fix but better than it was....

 

[primitivo]

I am so angry at Asus because of this. Apparently they acknowledged there is a bug but no ETA on fixing this. It would be great if Merlin with his insider contacts push Asus to fix this asap (yes I know Merlin doesn't touch WAN but still can force Asus to have a look ASAP at this major bug). There must be an issue if so many users are reporting the same.

"On the phone with the Asus tech lady, she mentioned that it is a known issue/bug. They have no ETA on when it will be fixed. "

Check here and here.

Here is the problem with this bug:
- happens with Automatic IP setting
- when Asus is connected to device working in a bridge mode
- it can drop WAN DHCP lease 10 times per day
- it can work sometimes even 3 days without dropping (usually after fresh reboot).
- there is no way to reproduce this bug
- it is not happening when there is a router NAT in front of Asus instead of bridge but then we have double NAT issue

 

[eddiez]

I am so angry at Asus because of this. Apparently they acknowledged there is a bug but no ETA on fixing this.

Can imagine that, but...

- it can work sometimes even 3 days without dropping (usually after fresh reboot).
- there is no way to reproduce this bug

If an issue is not reproducible on the router a root cause is not easily to be investigated, so it's quite impossible to provide a date for a fix. You don't know what to fix or if it maybe is an environment issue... So please be a bit more realistic with pointing the finger.

 

[primitivo]

[...]
If an issue is not reproducible on the router a root cause is not easily to be investigated, so it's quite impossible to provide a date for a fix. You don't know what to fix or if it maybe is an environment issue... So please be a bit more realistic with pointing the finger.

Not sure if you understand but I am expecting for basic feature such as Automatic IP (WAN DHCP) to work properly. If it can work properly on $30 routers, it should work faultless on $300 routers. Beside if you read the links provided, you will see that Asus is suggesting downgrading the firmware via their recovery tools, which is kind of silly.

Either Asus get their things fixed or they will start losing customers. As much as I am big fan of them and Merlin, this WAN dropping is seriously unacceptable in premium grade home routers. I don't have this issue for AC56U PPPoE setting in one place, I don't have this issue on their DSL-AC68U PPPoE in another place but I do have this issue for Automatic IP connected to bridged modem in AC68U in 3rd place. It just seems if there is bridged connection and automatic IP, Asus fails in stability of WAN DHCP handling.

 

[eddiez]

Not sure if you understand but I am expecting for basic feature such as Automatic IP (WAN DHCP) to work properly. If it can work properly on $30 routers, it should work faultless on $300 routers. Beside if you read the links provided, you will see that Asus is suggesting downgrading the firmware via their recovery tools, which is kind of silly.

Either Asus get their things fixed or they will start losing customers. As much as I am big fan of them and Merlin, this WAN dropping is seriously unacceptable in premium grade home routers. I don't have this issue for AC56U PPPoE setting in one place, I don't have this issue on their DSL-AC68U PPPoE in another place but I do have this issue for Automatic IP connected to bridged modem in AC68U in 3rd place. It just seems if there is bridged connection and automatic IP, Asus fails in stability of WAN DHCP handling.

Haven't seen these issues with tens or hundreds of Asus owners, nor here locally. So the impact of this 'bug' seems to be limited. And what I am saying is that since reproducing the observed instability seems impossible, you nor Asus can determine for sure that it is actually the ASUS WAN that is causing the observed issues. And that fact (yes, fact) should lead to some restraints in pointing your finger towards Asus. Prove the Asus WAN to be at fault and your claim would be justified.

 

[primitivo]

Haven't seen these issues with tens or hundreds of Asus owners, nor here locally. So the impact of this 'bug' seems to be limited. And what I am saying is that since reproducing the observed instability seems impossible, you nor Asus can determine for sure that it is actually the ASUS WAN that is causing the observed issues. And that fact (yes, fact) should lead to some restraints in pointing your finger towards Asus. Prove the Asus WAN to be at fault and your claim would be justified.

Just google: "Asus dropping WAN" and you will see the justification. Also many users who have been fighting, simply gave up, bought a Netgear and never seen this issue again. So if not Asus is at fault then who?

 

[eddiez]

Just google: "Asus dropping WAN" and you will see the justification. Also many users who have been fighting, simply gave up, bought a Netgear and never seen this issue again. So if not Asus is at fault then who?

Stating your case by referring to a 'generic' google search is simply no justification of your rant. But you're angry about your issues, so if this eases your mind....

And please let us know how to resolve an issue that cannot be reproduced. My dev teams would love to learn that trick.

 

[primitivo]

Stating your case by referring to a 'generic' google search is simply no justification of your rant. But you're angry about your issues, so if this eases your mind....

And please let us know how to resolve an issue that cannot be reproduced. My dev teams would love to learn that trick.

That's simple. Put back old WAN DHCP protocol from firmwares they are asking you to downgrade to. If they kind of acknowledge the issue and they know in which FWs the issues do not exist, they should know where the mistakes have been made and how to address them. Otherwise it's a sign of a poor development team.

 

[eddiez]

That's simple. Put back old WAN DHCP protocol from firmwares they are asking you to downgrade to. If they kind of acknowledge the issue and they know in which FWs the issues do not exist, they should know where the mistakes have been made and how to address them. Otherwise it's a sign of a poor development team.

Let's assume that the dev teams at Asus are not novices... what would 'not reproducible' mean to them do you think? If it were that simple, then there would be no other conclusion that the number of impact clients is so low that fixing it in this simple fashion would not be worth while...

 

[primitivo]

Let's assume that the dev teams at Asus are not novices... what would 'not reproducible' mean to them do you think? If it were that simple, then there would be no other conclusion that the number of impact clients is so low that fixing it in this simple fashion would not be worth while...

I am just saying and asking Merlin to put this Asus shame to end by pushing them to fix or even rewriting the whole WAN DHCP protocol. What is not reproducible from above-average user, does not mean that it cannot be reproduced under some stress development tests by "not novice" dev team.

 

[eddiez]

I am just saying and asking Merlin to put this Asus shame to end by pushing them to fix or even rewriting the whole WAN DHCP protocol. What is not reproducible from above-average user, does not mean that it cannot be reproduced under some stress development tests by "not novice" dev team.

You assume too much, let's leave it that. Good luck with your next Netgear.

 

[primitivo]

So I have flashed Tomato Shibby v138 over Merlin 380.61 on RT-AC68U and the WAN DHCP issue is gone. The connection has been rock solid for more than a week now with watchdog enabled.

Highly recommended to those with the problems above until guys in the suits will learn how to fix or implement basic functionality right.