Is this a bug on Asus firmware? WAN disconnections

[frustin]

also got this issue. every night my WAN disappears. each morning i pick up the iphone log into the router and reboot. all better.

Thing is it went away for a few months and started again last week, it's done it each day since.

I use cat 6 cable. i updated to latest firmware. I can only think that it must be the virgin cable box (superwhatsitsname) or the line.

 

[RMerlin]

also got this issue. every night my WAN disappears. each morning i pick up the iphone log into the router and reboot. all better.

Thing is it went away for a few months and started again last week, it's done it each day since.

I use cat 6 cable. i updated to latest firmware. I can only think that it must be the virgin cable box (superwhatsitsname) or the line.

Is your DHCP lease also set to expire at about the time it fails? If so, then it would imply the issue has to do with the lease failing to renew.

Check your System Log - it will give you a lot of info as to what is happening during the night. Otherwise, you'll be chasing blind.

 

[Agent0071]

Thanks for the help. I called the cable company (Charter) and they sent out a tech. He was in and out in 15 mins. I wasn't home. He told my wife I had too many things connecting for my model modem. He told her he upgraded it from a "4" to an "8" whatever that means. They changed me from a Cisco DPC 3010 modem to a Arris TM822. So the router was fine, it was the modem as Merlin proposed. Thanks again.

 

[theirongiant]

I dealt with this issue in the morning, left it alone and came back at night.

My ISP is Charter. I was finally able to get a manager on the phone and he indicated several helpful tips for troubleshooting this problem.

1) The error message in Charter's logs is "DHCP Lease Denied."

2) He read the internal documentation about this problem. Summary:

Charter Internet Service customers using PC’s which exhibit “chatty or erratic network behavior” are denied a connection by the DHCP server. If a device is sending signals that Charter deems "unacceptable," the DHCP server will not provide a new address.

The device is considered “chatty” if it sends more than 5 requests in a 30 second period. The minimum period of silence (no requests) before a device will be unblocked is 150 seconds.

Merlin, please inform your ASUS partners about these helpful details and incorporate the changes in your router. Is there a way to program the router's DHCP client to politely "shut the hell up" for 150 seconds when a DHCP error from the ISP is noted in the log?

Cheers,
The Iron Giant

 

[RMerlin]

Merlin, please inform your ASUS partners about these helpful details and incorporate the changes in your router. Is there a way to program the router's DHCP client to politely "shut the hell up" for 150 seconds when a DHCP error from the ISP is noted in the log?

That was already implemented months ago. Set DHCP query frequency to "Normal" instead of the default "Aggressive" on the WAN page - that option was specifically implemented for Charter.

 

[theirongiant]

That was already implemented months ago. Set DHCP query frequency to "Normal" instead of the default "Aggressive" on the WAN page - that option was specifically implemented for Charter.

Thanks for the reply. I have been following and using your firmware since I bought the RT-N66U back in the summertime, and that you had implemented the Normal / Aggressive setting to deal with Charter. Unfortunately, I had it set to Normal and was still having this issue. I am using 3.0.0.4.374.35_4-sdk5.

I posted this information in case you needed more specifics about the timing (I assumed this was not public knowledge). It would be helpful if the "Normal" setting also quieted the DHCP requests for at least 3 minutes in case of disconnect. Or does it already do this?

 

[RMerlin]

Thanks for the reply. I have been following and using your firmware since I bought the RT-N66U back in the summertime, and that you had implemented the Normal / Aggressive setting to deal with Charter. Unfortunately, I had it set to Normal and was still having this issue. I am using 3.0.0.4.374.35_4-sdk5.

I posted this information in case you needed more specifics about the timing (I assumed this was not public knowledge). It would be helpful if the "Normal" setting also quieted the DHCP requests for at least 3 minutes in case of disconnect. Or does it already do this?

It currently sends a maximum of two packets every 2 minutes, which should not trigger the blacklisting. The delays were based on Charter's limitations that were public at the time of their implementation (last year).

 

[theirongiant]

It currently sends a maximum of two packets every 2 minutes, which should not trigger the blacklisting. The delays were based on Charter's limitations that were public at the time of their implementation (last year).

The documentation he read to me was internal. 150 seconds is longer than 2 minutes (120 seconds).

 

[RMerlin]

The documentation he read to me was internal. 150 seconds is longer than 2 minutes (120 seconds).

150 seconds is to get unblocked. 120 seconds is to ensure you never get blocked in the first place.

 

[theirongiant]

Well, it happened again last night after less than 12 hours runtime. The log is attached, starting at the disconnection, and ending at the reconnection. Single periods indicate that the previous line was repeated.

 

[RMerlin]

Well, it happened again last night after less than 12 hours runtime. The log is attached, starting at the disconnection, and ending at the reconnection. Single periods indicate that the previous line was repeated.

If your Ethernet port is flip-flopping like I see in your logs then you will need to address that issue. Ethernet port going down means that your modem just rebooted - this shouldn't happen unless there was a problem with it. This isn't caused by a lease expiring.

 

[Danmac]

also got this issue. every night my WAN disappears. each morning i pick up the iphone log into the router and reboot. all better.

Thing is it went away for a few months and started again last week, it's done it each day since.

I use cat 6 cable. i updated to latest firmware. I can only think that it must be the virgin cable box (superwhatsitsname) or the line.

Just the same case than me...

I´ve turned off my modem and also the router a week ago (for half and hour) and now it seems to be working (4 days in a row ).

I´ve got some log messages in both machines but they don´t match in time.
Asus:

Dec 12 02:04:08 miniupnpd[1180]: Expired NAT-PMP mapping port 39665 UDP removed
Dec 12 02:04:08 miniupnpd[1180]: Expired NAT-PMP mapping port 39665 TCP removed
Dec 12 15:26:44 miniupnpd[1180]: Expired NAT-PMP mapping port 39665 UDP removed
Dec 12 15:26:44 miniupnpd[1180]: Expired NAT-PMP mapping port 39665 TCP removed

Modem:

Wed Dec 11 06:24:55 2013 Critical (3) Started Unicast Maintenance Ranging - No Response received - ...

Before this thing I tried I was receiving same messages you can see in this thread:
-WAN Connection: WAN was restored.
-Dhcp client: bound IP
-...

So far, so good except one thing:
-Power led is blinking (slowly)

But it works

 

[theirongiant]

It happened again, at around the same time of night. I will continue to log each outage. Also, this reminds me why I switched to Tomato many months ago: I started having this problem right away when the RT-N66U router was brand new. I tried the stock firmware for about a month, then I switched to yours. But it kept happening.

The WAN outages finally STOPPED when I installed TomatoUSB (I happen to use the Shibby variant). My router went 45 days straight without a reboot or a WAN failure. In fact, the only time the WAN went down and stayed down was when the DHCP lease expired, and I hadn't configured TomatoUSB to be less aggressive in its requests.

 

[RMerlin]

You don't seem to be reading my answer... Here's one last time:

Dec 12 23:32:50 WAN Connection: Ethernet link down.

This indicates a problem with your modem, which has spontaneously rebooted itself. You have to fix that. It has nothing to do with the ISP lease, this error message indicates the link PHYSICALLY went down.

 

[theirongiant]

You don't seem to be reading my answer... Here's one last time:

Dec 12 23:32:50 WAN Connection: Ethernet link down.

This indicates a problem with your modem, which has spontaneously rebooted itself. You have to fix that. It has nothing to do with the ISP lease, this error message indicates the link PHYSICALLY went down.

OK. I had Charter come over yesterday afternoon to repair the jack on the wall. The technician didn't install it right in the first place, and there was a splitter outside in the junction box. Our signals were already well within parameters (45dBmV Upstream, -2 to +3dBmV Downstream on all four channels). Removing the splitter and fixing the jack brought it down a few ticks.

The modem still rebooted last night around 12:30AM.

It's a Surfboard 6121. I'm considering the 6141...

 

[ikoul]

The Surfboard 61x1 modems have notoriously been very sensitive to signal changes. When I was on Comcast on a 6121 it would reboot multiple times a day just due to the normal signal fluctuations throughout the day (it got slightly better after a firmware upgrade they pushed to the modem at some point). Now I'm using a 6141 on another ISP and it has been fine (I upgraded to the 6141 so that I could get 100Mbps service when I moved).

The only real troubleshooting you can do with these modems that doesn't involve calling your ISP is to power cycle it or reset to factory defaults and let it resync its settings.

 

[RMerlin]

OK. I had Charter come over yesterday afternoon to repair the jack on the wall. The technician didn't install it right in the first place, and there was a splitter outside in the junction box. Our signals were already well within parameters (45dBmV Upstream, -2 to +3dBmV Downstream on all four channels). Removing the splitter and fixing the jack brought it down a few ticks.

The modem still rebooted last night around 12:30AM.

It's a Surfboard 6121. I'm considering the 6141...

Since it's a complete modem reboot and not just the WAN connection dropping according to the log entry, the issue is with the modem itself and not with the signal.

I also saw quite a few reported issues with the 6121 on these forums, usually solved by switching to a different modem. Personally I use a Thomson DCM475, been working flawlessly for about 8 months now (when I ditched DSL).

 

[theirongiant]

Since it's a complete modem reboot and not just the WAN connection dropping according to the log entry, the issue is with the modem itself and not with the signal.

I also saw quite a few reported issues with the 6121 on these forums, usually solved by switching to a different modem. Personally I use a Thomson DCM475, been working flawlessly for about 8 months now (when I ditched DSL).

I noticed in the product notes on Newegg that the SB6141 has a lowpass filter at 1GHz to guard against interference from MoCA, or Multimedia Over CoAx. What do you know about this feature?

 

[RMerlin]

I noticed in the product notes on Newegg that the SB6141 has a lowpass filter at 1GHz to guard against interference from MoCA, or Multimedia Over CoAx. What do you know about this feature?

This is probably intended for people who use both MOCA and a modem on their internal RG59 coax cabling. Kinda similar to the line filters allowing people to have both DSL and regular voice service at the same time on their phone line.

 

[goodie]

same problem with my ac66u router. here the log.

modem is on, and connect to wan, you can tell by the led lights.
modem Ethernet was cutoff , NO led lit.
router stated connected to wan.
No internet connection, have tried.
power off ac66u, and the router was able to assign a new ip address
to the modem, online again.
Does it help?

Jan 2 15:11:30 dnsmasq-dhcp[377]: DHCPACK(br0) 192.168.1.106 00:19:66:f6:1f:12 home-PC
Jan 2 15:12:14 WAN Connection: Ethernet link up.
Jan 2 15:12:14 rc_service: wanduck 291:notify_rc restart_wan_if 0
Jan 2 15:12:14 dnsmasq[377]: read /etc/hosts - 5 addresses
Jan 2 15:12:14 dnsmasq[377]: using nameserver 209.18.47.62#53
Jan 2 15:12:14 dnsmasq[377]: using nameserver 209.18.47.61#53
Jan 2 15:12:14 stop_wan(): perform DHCP release
Jan 2 15:12:14 miniupnpd[422]: ioctl(s, SIOCGIFADDR, ...): Cannot assign requested address
Jan 2 15:12:14 miniupnpd[422]: Failed to get IP for interface eth0
Jan 2 15:12:14 miniupnpd[422]: SendNATPMPPublicAddressChangeNotification: cannot get public IP address, stopping
Jan 2 15:12:14 miniupnpd[422]: ioctl(s, SIOCGIFADDR, ...): Cannot assign requested address
Jan 2 15:12:14 miniupnpd[422]: ioctl(s, SIOCGIFADDR, ...): Cannot assign requested address
Jan 2 15:12:14 dnsmasq[377]: read /etc/hosts - 5 addresses
Jan 2 15:12:14 dnsmasq[377]: using nameserver 209.18.47.62#53
Jan 2 15:12:14 dnsmasq[377]: using nameserver 209.18.47.61#53
Jan 2 15:12:14 kernel: br0: port 1(vlan1) entering disabled state
Jan 2 15:12:14 kernel: vlan1: dev_set_promiscuity(master, 1)
Jan 2 15:12:14 kernel: br0: port 1(vlan1) entering listening state
Jan 2 15:12:14 kernel: br0: port 1(vlan1) entering learning state
Jan 2 15:12:14 dnsmasq[377]: read /etc/hosts - 5 addresses
Jan 2 15:12:14 kernel: br0: topology change detected, propagating
Jan 2 15:12:14 kernel: br0: port 1(vlan1) entering forwarding state
Jan 2 15:12:14 dnsmasq[377]: read /etc/hosts - 5 addresses
Jan 2 15:12:14 dnsmasq[377]: using nameserver 209.18.47.62#53
Jan 2 15:12:14 dnsmasq[377]: using nameserver 209.18.47.61#53
Jan 2 15:12:14 start_nat_rules: apply the nat_rules(/tmp/nat_rules_eth0_eth0)!
Jan 2 15:12:14 dnsmasq[377]: exiting on receipt of SIGTERM
Jan 2 15:12:14 dnsmasq[576]: started, version 2.67 cachesize 1500
Jan 2 15:12:14 dnsmasq[576]: compile time options: IPv6 GNU-getopt no-RTC no-DBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP no-conntrack no-ipset no-auth
Jan 2 15:12:14 dnsmasq[576]: warning: interface ppp1* does not currently exist
Jan 2 15:12:14 dnsmasq[576]: asynchronous logging enabled, queue limit is 5 messages
Jan 2 15:12:14 dnsmasq-dhcp[576]: DHCP, IP range 192.168.1.2 -- 192.168.1.254, lease time 1d
Jan 2 15:12:14 dnsmasq[576]: read /etc/hosts - 5 addresses
Jan 2 15:12:14 dnsmasq[576]: using nameserver 209.18.47.62#53
Jan 2 15:12:14 dnsmasq[576]: using nameserver 209.18.47.61#53
Jan 2 15:12:15 rc_service: udhcpc 558:notify_rc stop_upnp
Jan 2 15:12:15 rc_service: udhcpc 558:notify_rc start_upnp
Jan 2 15:12:15 miniupnpd[591]: HTTP listening on port 52415
Jan 2 15:12:15 miniupnpd[591]: Listening for NAT-PMP traffic on port 5351
Jan 2 15:12:15 dhcp client: bound 74.73.127.113 via 74.73.120.1 during 33813 seconds.
Jan 2 15:12:32 dnsmasq-dhcp[576]: DHCPINFORM(br0) 192.168.1.106 00:19:66:f6:1f:12