Is this a bug on Asus firmware? WAN disconnections

[bill0042]

I bet you are using a Cat5 Ethernet cable between the router and the modem. RT-N66U has a gigabit WAN interface, so it needs to be either Cat5e or Cat6.

Also when switching a cablemodem to a new router, you need to fully reset the connection, usually by leaving the cablemodem turned off for 5-10 mins.

I don't know what kind of cable is between my modem and router since they are in different rooms and using the internal wiring in my house. Would it help if I put a switch between the router and wall outlet and use cat6 or cat5e between the router and switch?

 

[Wutikorn]

Would it help if I put a switch between the router and wall outlet and use cat6 or cat5e between the router and switch?

No, it usually won't help. As long as there is Cat5(or poor quality Cat5e) in between, the connection will be maximum at 100Mbps.

 

[Scott Jacobs]

I am a single WAN connection, but .59 was rock solid and .62_1 has been a mess. Just moved to .63 beta to see if it works better.

OK - definitely interested to see if that level has helped it all. Really would like to avoid going backwards. For me this is more of a once a day annoyance based on the current DHCP expiration for comcast. From my logs it looks like things take about a minute or to before my connection ends up switching back to my primary lan connection.

 

[bill0042]

No, it usually won't help. As long as there is Cat5(or poor quality Cat5e) in between, the connection will be maximum at 100Mbps.

Thanks for the reply. My DSL connection is only 80Mbps so I don't worry about only having a 100Mbps connection between the modem and router. My main issue is having a lot of dropped connections when gaming

 

[Wutikorn]

Thanks for the reply. My DSL connection is only 80Mbps so I don't worry about only having a 100Mbps connection between the modem and router. My main issue is having a lot of dropped connections when gaming

Do you know if you can ping your modem? Try to ping to router, modem, and a website(www.google.com for example) at the same time. If you have stable ping between your PC and router and between PC and modem(shouldn't be more than 10ms each), but ping to website is bad, it's probably sth ISP should fix. However, if ping to router is stable, but ping to modem is bad, either router(on WAN part), modem or cable between the two is bad.

 

[beerkeen]

Hi, All! This is my first post, sorry for my english. I have known bug:

Nov  1 20:17:05 WAN Connection: Ethernet link down.
Nov  1 20:17:05 stop_nat_rules: apply the redirect_rules!
Nov  1 20:17:20 WAN Connection: Ethernet link up.
Nov  1 20:17:20 rc_service: wanduck 219:notify_rc restart_wan_if 0
Nov  1 20:17:20 kernel: Attempt to kill tasklet from interrupt
Nov  1 20:17:20 miniupnpd[7707]: ioctl(s, SIOCGIFADDR, ...): Cannot assign requested address
Nov  1 20:17:20 miniupnpd[7707]: Failed to get IP for interface eth0
Nov  1 20:17:20 miniupnpd[7707]: SendNATPMPPublicAddressChangeNotification: cannot get public IP address, stopping
Nov  1 20:17:20 miniupnpd[7707]: ioctl(s, SIOCGIFADDR, ...): Cannot assign requested address
Nov  1 20:17:20 miniupnpd[7707]: ioctl(s, SIOCGIFADDR, ...): Cannot assign requested address
Nov  1 20:17:20 rc_service: udhcpc 7809:notify_rc start_firewall
Nov  1 20:17:20 start_nat_rules: apply the nat_rules(/tmp/nat_rules_eth0_eth0)!
Nov  1 20:17:21 wan: finish adding multi routes
Nov  1 20:17:21 rc_service: udhcpc 7809:notify_rc stop_upnp
Nov  1 20:17:21 rc_service: udhcpc 7809:notify_rc start_upnp
Nov  1 20:17:21 rc_service: waitting "stop_upnp" via udhcpc ...
Nov  1 20:17:21 miniupnpd[7707]: shutting down MiniUPnPd
Nov  1 20:17:22 dhcp client: bound 31.207.193.16 via 31.207.192.1 during 1800 seconds.
Nov  1 20:17:22 ntp: start NTP update
Nov  1 20:17:22 miniupnpd[7846]: HTTP listening on port 41711
Nov  1 20:17:22 miniupnpd[7846]: Listening for NAT-PMP/PCP traffic on port 5351
Nov  1 20:17:26 WAN Connection: WAN was restored.
Nov  1 23:38:24 WAN Connection: Ethernet link down.
Nov  1 23:38:24 stop_nat_rules: apply the redirect_rules!
Nov  1 23:38:38 WAN Connection: Ethernet link up.
Nov  1 23:38:38 rc_service: wanduck 219:notify_rc restart_wan_if 0
Nov  1 23:38:38 miniupnpd[7846]: ioctl(s, SIOCGIFADDR, ...): Cannot assign requested address
Nov  1 23:38:38 miniupnpd[7846]: Failed to get IP for interface eth0
Nov  1 23:38:38 miniupnpd[7846]: SendNATPMPPublicAddressChangeNotification: cannot get public IP address, stopping
Nov  1 23:38:38 miniupnpd[7846]: ioctl(s, SIOCGIFADDR, ...): Cannot assign requested address
Nov  1 23:38:38 miniupnpd[7846]: ioctl(s, SIOCGIFADDR, ...): Cannot assign requested address
Nov  1 23:38:38 kernel: Attempt to kill tasklet from interrupt
Nov  1 23:38:41 rc_service: udhcpc 7948:notify_rc start_firewall
Nov  1 23:38:41 start_nat_rules: apply the nat_rules(/tmp/nat_rules_eth0_eth0)!
Nov  1 23:38:41 wan: finish adding multi routes
Nov  1 23:38:41 rc_service: udhcpc 7948:notify_rc stop_upnp
Nov  1 23:38:41 rc_service: udhcpc 7948:notify_rc start_upnp
Nov  1 23:38:41 rc_service: waitting "stop_upnp" via udhcpc ...
Nov  1 23:38:41 miniupnpd[7846]: shutting down MiniUPnPd
Nov  1 23:38:42 dhcp client: bound 31.207.193.16 via 31.207.192.1 during 1800 seconds.
Nov  1 23:38:42 ntp: start NTP update
Nov  1 23:38:42 miniupnpd[7985]: HTTP listening on port 38733
Nov  1 23:38:42 miniupnpd[7985]: Listening for NAT-PMP/PCP traffic on port 5351
Nov  1 23:38:46 WAN Connection: WAN was restored.
Nov  2 01:55:07 miniupnpd[7985]: remove port mapping 55672 UDP because it has expired

Router - ASUS RT-N66U. Firmware version - 380.62_1. Provider says - all OK. Cable. 100 Mb/s. Direct connection. I can hope for solving this problem? May be FAQ? Ready for additional questions. I like this firmware and want to use it.

 

[RMerlin]

Nov 1 20:17:05 WAN Connection: Ethernet link down.
Nov 1 20:17:05 stop_nat_rules: apply the redirect_rules!
Nov 1 20:17:20 WAN Connection: Ethernet link up

The problem is your modem, not the router. This indicates that your modem rebooted.

 

[beerkeen]

The problem is your modem, not the router. This indicates that your modem rebooted.

I have not modem. I have ethernet WAN connect. Previously, when i use original ASUS firmware, i do not have this problem

 

[RMerlin]

I have not modem. I have ethernet WAN connect. Previously, when i use original ASUS firmware, i do not have this problem

Every connection has to have a modem of some sort. Ethernet can only transmit over 100m, there's a modem somewhere that takes the DSL/DOCSIS/fibre connection that reaches your building and converts it into an Ethernet connection.

What the log shows is that the connection drops for 5-10 secs at the Ethernet port, then it comes back.

 

[beerkeen]

Every connection has to have a modem of some sort. Ethernet can only transmit over 100m, there's a modem somewhere that takes the DSL/DOCSIS/fibre connection that reaches your building and converts it into an Ethernet connection.

You wouldn't believe me, but my provider don't use modems. Ethernet only (+ may be repeaters). My building in two hundred meters from the provider's building. And important! I almost sure - drops occur when DHCP leases expire. Router somehow does not receive ip address immediately. But provider said that his DHCP server is OK.

 

[Scott Jacobs]

I am a single WAN connection, but .59 was rock solid and .62_1 has been a mess. Just moved to .63 beta to see if it works better.

I ended up applying the .63 firmware this week - and as I expected - there was no change in this behavior. Definitely something that ASUS changed to cause this - as I have a number of other routers - including a TP link that I recently switched from because they were no longer providing firmware updates for it - and never seen the issue. I might buy it that Comcast did something on their end to trigger this - but I have both Comcast and Uverse and they are both exhibiting the same issue - only commonality is the Asus router.

 

[Kim Puleston]

I ended up applying the .63 firmware this week - and as I expected - there was no change in this behavior. Definitely something that ASUS changed to cause this - as I have a number of other routers - including a TP link that I recently switched from because they were no longer providing firmware updates for it - and never seen the issue. I might buy it that Comcast did something on their end to trigger this - but I have both Comcast and Uverse and they are both exhibiting the same issue - only commonality is the Asus router.

I agree, there us something unique to the Asus Firmware as this has only started since I got my AC88U. driving me mad having to keep rebooting the router to restablish a connection

 

[Scott Jacobs]

I agree, there us something unique to the Asus Firmware as this has only started since I got my AC88U. driving me mad having to keep rebooting the router to restablish a connection

I have been doing some additional testing. The first thing I did was to change the setting on both of my WAN connections "Connect to DNS servers automatically" to No from Yes - and supplied the two Google DNS servers, which is what I have my DHCP server configured for. Anyhow - that made no difference either. So now I am testing just running with a single WAN connection - turned dual WAN off. Will see how that works over the next day or so. If it goes more than 12-24 hours without triggering that error message and dropping and restoring the connection - I will know that I have found the culprit for my setup. I have been considering dropping my secondary connection - but since I work from home every day all day - it is nice to have that as a backup.

 

[Kim Puleston]

I have been doing some additional testing. The first thing I did was to change the setting on both of my WAN connections "Connect to DNS servers automatically" to No from Yes - and supplied the two Google DNS servers, which is what I have my DHCP server configured for. Anyhow - that made no difference either. So now I am testing just running with a single WAN connection - turned dual WAN off. Will see how that works over the next day or so. If it goes more than 12-24 hours without triggering that error message and dropping and restoring the connection - I will know that I have found the culprit for my setup. I have been considering dropping my secondary connection - but since I work from home every day all day - it is nice to have that as a backup.

I should test that one as well really, I have a single WAN setup however.

 

[Kim Puleston]

Update.

So 24 hours later and my WAN has not dropped. The only change that I have made is to disable traffic analysis. I will see how this moves forward and will let you guys know the outcome. I have read Traffic analysis causing other issues ehich leads me to try disabling it...we will see.

 

[Scott Jacobs]

Update.

So 24 hours later and my WAN has not dropped. The only change that I have made is to disable traffic analysis. I will see how this moves forward and will let you guys know the outcome. I have read Traffic analysis causing other issues ehich leads me to try disabling it...we will see.

Interesting - well - for me - I have been running now for about 2 days and have not experienced any drop or message like I had been seeing multiple times a day saying that my ISP had a DHCP problem. The only change that I had made beyond turning off getting the DNS from the ISP (which didn't have any effect for me) was to change from dual WAN to single WAN. I have not experienced the problem with a single WAN setup. I do have traffic analysis turned on - but I do not have any of the AI protection stuff turned on. Do you happen to have any of the AI protect features turned on? Seems like my results are not consistent with yours for whatever reason...

 

[Kim Puleston]

Interesting - well - for me - I have been running now for about 2 days and have not experienced any drop or message like I had been seeing multiple times a day saying that my ISP had a DHCP problem. The only change that I had made beyond turning off getting the DNS from the ISP (which didn't have any effect for me) was to change from dual WAN to single WAN. I have not experienced the problem with a single WAN setup. I do have traffic analysis turned on - but I do not have any of the AI protection stuff turned on. Do you happen to have any of the AI protect features turned on? Seems like my results are not consistent with yours for whatever reason...

Well it seems that perhaps people will have different results depending upon ISP perhaps ? I am now 48 hours in with no disconnections after disabling Traffic Analysis which is fine by me as I do not really use it. I still however have AI Protection on. For anyone interested I am using Sky broadband

 

[Kim Puleston]

As an update I am 72 hours in with no WAN drop. So I think it is safe to say that Traffic Analysis is the cause for the WAN drops, at least in my case.

 

[Scott Jacobs]

As an update I am 72 hours in with no WAN drop. So I think it is safe to say that Traffic Analysis is the cause for the WAN drops, at least in my case.

Or perhaps Traffic Analysis along with AI protection. I am going to try enabling AI protection on my router. As we have discussed - I have Traffic Analysis enabled on mine - but not AI protection - so I am wondering if it is more the combination of these 2 features that could be causing / contributing to the WAN disconnects. Will set that up tonight and see how things look in the morning. Typically when I was having the issue - I would have several occurrences of the DHCP messages along with the disconnects within a span of 12-24 hours. So should not take long to know one way or the other.

 

[primitivo]

I have flashed RT-AC68U with 380.64 over 380.62 on the 20th of December and have not experienced any single WAN drop since then, which is now 5 days. Before there were 2-3 drops every day. I can't see any major fixes or changes to WAN implementation, unless it has been patched by Asus and not mentioned by Merlin in the changelog?