Is this a bug on Asus firmware? WAN disconnections

[randomname00]

Similar Issue

Hello, thank you for sharing your experiences. There is some comfort in knowing you aren't the only one having this issue.

Like many who have posted, I am getting the same message "ISP's DHCP did not function properly."

ISP: Charter.net
Cable Modem: Motorola SB6121 (Purchased March 2012)
Router: Asus RT-N66U (Purchased March 2012) FW: 3.0.0.4.370_172
Network Cable: Cat 6


For me, the disconnects started happening with the last two versions of Firmware. When the disconnects happen (usually one a day as of late), I login to the router, turn the WAN port off, then reboot the modem and re-enable the WAN port (does the trick each time... if I do not turn the WAN port off before rebooting, it won't work). Another option is to physically disconnect the WAN port from the Cable Modem before rebooting.

I put a ticket into Asus, but they told me the router needs to be sent back for repair. I doubt it is a hardware issue. I am going to dig up an older firmware and see what happens.

I have used various Linksys, D-Link, Xincom routers in the past without this issue. I like ASUS products, which is why I decided to try their router. I hope this issue can be resolved without laying out more money.

 

[RMerlin]

Hello, thank you for sharing your experiences. There is some comfort in knowing you aren't the only one having this issue.

Like many who have posted, I am getting the same message "ISP's DHCP did not function properly."

ISP: Charter.net
Cable Modem: Motorola SB6121 (Purchased March 2012)
Router: Asus RT-N66U (Purchased March 2012) FW: 3.0.0.4.370_172
Network Cable: Cat 6


For me, the disconnects started happening with the last two versions of Firmware. When the disconnects happen (usually one a day as of late), I login to the router, turn the WAN port off, then reboot the modem and re-enable the WAN port (does the trick each time... if I do not turn the WAN port off before rebooting, it won't work). Another option is to physically disconnect the WAN port from the Cable Modem before rebooting.

I put a ticket into Asus, but they told me the router needs to be sent back for repair. I doubt it is a hardware issue. I am going to dig up an older firmware and see what happens.

I have used various Linksys, D-Link, Xincom routers in the past without this issue. I like ASUS products, which is why I decided to try their router. I hope this issue can be resolved without laying out more money.

With Charter you need to set the DHCP mode to "Normal" if it was set to Aggressive. The option is on the WAN page.

Also see if your log shows the same DHCP lease issue as recently noticed. If it does, then the problem is the modem.

 

[bodean]

With Charter you need to set the DHCP mode to "Normal" if it was set to Aggressive. The option is on the WAN page.

Does this also need to be down for Comcast/Xfinity? Or is aggressive ok for them

 

[RMerlin]

Does this also need to be down for Comcast/Xfinity? Or is aggressive ok for them

No idea. I know Charter blacklists MACs if you send too many requests in a short period of time, don't know about other ISPs.

 

[Requi3m]

Hello, thank you for sharing your experiences. There is some comfort in knowing you aren't the only one having this issue.

Like many who have posted, I am getting the same message "ISP's DHCP did not function properly."

ISP: Charter.net
Cable Modem: Motorola SB6121 (Purchased March 2012)
Router: Asus RT-N66U (Purchased March 2012) FW: 3.0.0.4.370_172
Network Cable: Cat 6


For me, the disconnects started happening with the last two versions of Firmware. When the disconnects happen (usually one a day as of late), I login to the router, turn the WAN port off, then reboot the modem and re-enable the WAN port (does the trick each time... if I do not turn the WAN port off before rebooting, it won't work). Another option is to physically disconnect the WAN port from the Cable Modem before rebooting.

I put a ticket into Asus, but they told me the router needs to be sent back for repair. I doubt it is a hardware issue. I am going to dig up an older firmware and see what happens.

I have used various Linksys, D-Link, Xincom routers in the past without this issue. I like ASUS products, which is why I decided to try their router. I hope this issue can be resolved without laying out more money.

Did you check the logs for your modem? I posted the link for you to do so on the previous page. I'm betting it's your modem.

 

[Kobold]

As I see, I'm not alone. My router suffers from this trouble too.

Like many who have posted, I am getting the same message "ISP's DHCP did not function properly."

What does the router expect from the ISP? In which case is it satisfied with the ISP and not telling "ISP's DHCP did not function properly."? Maybe if we figure it out we can find a solution?

 

[RMerlin]

As I see, I'm not alone. My router suffers from this trouble too.

What does the router expect from the ISP? In which case is it satisfied with the ISP and not telling "ISP's DHCP did not function properly."? Maybe if we figure it out we can find a solution?

This message in itself is often bogus. It will usually display that message when it's currently booting and isn't really ready yet to ask for a lease. My own router does it too, and within 20-30 secs it sends another request, which gets answered and connects fine.

This message is only sign of a problem if it occurs multiple times, or long after the router has finished booting. It's essentially a generic error message the DHCP code returns if it couldn't obtain - or request - a lease.

 

[col2k3]

With Charter you need to set the DHCP mode to "Normal" if it was set to Aggressive. The option is on the WAN page.

Also see if your log shows the same DHCP lease issue as recently noticed. If it does, then the problem is the modem.

Is this option only in more recent firmwares? I can't find anything like it under WAN on mine.

 

[RMerlin]

Is this option only in more recent firmwares? I can't find anything like it under WAN on mine.

Was added around build 270, I forgot which specific version.

 

[joegreat]

"Ethernet link down" is almost certainly a sign of a problem at the Ethernet level, usually the cable. The router has a gigabit WAN port, so you need a gigabit-cable cable (Cat5e or better, and fairly recent RJ-45 connectors as well - I've seen older connectors having trouble dealing with gigabit speed).

Hi,

Sorry to reopen this thread, but I have the same issue.

What I did so far is:
- Changing cable between Router and Modem (running with Cat 5e and Cat 6 cables)
- Changing the WAN MAC address of the router to get a new IP address from my ISP
- Reseting the router and cable modem (>30 Min. power off)
- Tried WAN DHCP (lease time was 7 days!) vs. fixed IP settings
But nothing changed or helped to overcome the WLAN connection going down!

As you can see the WAN link goes quite regular down (every ~6-7 hours) and comes backup up after some seconds:

Jul 18 00:21:37 WAN Connection: Ethernet link down.
Jul 18 00:21:48 WAN Connection: Ethernet link up.
Jul 18 00:21:56 WAN Connection: WAN was restored.

Jul 18 07:56:34 WAN Connection: Ethernet link down.
Jul 18 07:56:45 WAN Connection: Ethernet link up.
Jul 18 07:56:53 WAN Connection: WAN was restored.

Jul 18 14:09:00 WAN Connection: Ethernet link down.
Jul 18 14:09:16 WAN Connection: Ethernet link up.
Jul 18 14:09:24 WAN Connection: WAN was restored.
Jul 18 14:09:29 WAN Connection: Ethernet link up.

Jul 18 19:49:54 WAN Connection: Ethernet link down.
Jul 18 19:50:08 WAN Connection: Ethernet link up.
Jul 18 19:50:16 WAN Connection: WAN was restored.
Jul 18 19:50:21 WAN Connection: Ethernet link up.

Jul 18 21:37:04 WAN Connection: Ethernet link down.
Jul 18 21:37:15 WAN Connection: Ethernet link up.
Jul 18 21:37:23 WAN Connection: WAN was restored.

Jul 19 02:01:26 WAN Connection: Ethernet link down.
Jul 19 02:01:42 WAN Connection: Ethernet link up.
Jul 19 02:01:45 WAN Connection: WAN was restored.

Jul 19 09:30:43 WAN Connection: Ethernet link down.
Jul 19 09:30:56 WAN Connection: Ethernet link up.
Jul 19 09:31:04 WAN Connection: WAN was restored.
Jul 19 09:31:10 WAN Connection: Ethernet link up.

Jul 19 15:38:55 WAN Connection: Ethernet link down.
Jul 19 15:39:07 WAN Connection: Ethernet link up.
Jul 19 15:39:15 WAN Connection: WAN was restored.

Jul 19 21:27:26 WAN Connection: Ethernet link down.
Jul 19 21:27:37 WAN Connection: Ethernet link up.
Jul 19 21:27:45 WAN Connection: WAN was restored.
Jul 19 21:27:50 WAN Connection: Ethernet link up.

Jul 20 03:44:01 WAN Connection: Ethernet link down.
Jul 20 03:44:17 WAN Connection: Ethernet link up.
Jul 20 03:44:25 WAN Connection: WAN was restored.

Jul 21 07:37:10 WAN Connection: Ethernet link down.
Jul 21 07:37:26 WAN Connection: Ethernet link up.
Jul 21 07:37:32 WAN Connection: ISP's DHCP did not function properly.
Jul 21 07:37:37 WAN Connection: Ethernet link up.
Jul 21 07:38:15 WAN Connection: WAN was restored.

Jul 21 13:48:34 WAN Connection: Ethernet link down.
Jul 21 13:48:45 WAN Connection: Ethernet link up.
Jul 21 13:48:51 WAN Connection: ISP's DHCP did not function properly.
Jul 21 13:51:03 WAN Connection: WAN was restored.

Jul 21 19:33:12 WAN Connection: Ethernet link down.
Jul 21 19:33:25 WAN Connection: Ethernet link up.
Jul 21 19:33:33 WAN Connection: WAN was restored.
Jul 21 19:33:38 WAN Connection: Ethernet link up.

Jul 22 01:18:38 WAN Connection: Ethernet link down.
Jul 22 01:18:48 WAN Connection: Ethernet link up.
Jul 22 01:18:56 WAN Connection: WAN was restored.
Jul 22 01:19:01 WAN Connection: Ethernet link up.

Jul 22 08:15:37 WAN Connection: Ethernet link down.
Jul 22 08:15:53 WAN Connection: Ethernet link up.
Jul 22 08:16:01 WAN Connection: WAN was restored.
Jul 22 08:16:06 WAN Connection: Ethernet link up.

Jul 22 14:27:36 WAN Connection: Ethernet link down.
Jul 22 14:27:47 WAN Connection: Ethernet link up.
Jul 22 14:27:55 WAN Connection: WAN was restored.
Jul 22 14:28:00 WAN Connection: Ethernet link up.

Jul 22 20:17:05 WAN Connection: Ethernet link down.
Jul 22 20:17:16 WAN Connection: Ethernet link up.
Jul 22 20:17:24 WAN Connection: WAN was restored.
Jul 22 20:17:29 WAN Connection: Ethernet link up.

Jul 23 02:40:29 WAN Connection: Ethernet link down.
Jul 23 02:40:38 WAN Connection: Ethernet link up.
Jul 23 02:40:46 WAN Connection: WAN was restored.

Jul 23 09:51:43 WAN Connection: Ethernet link down.
Jul 23 09:51:54 WAN Connection: Ethernet link up.
Jul 23 09:52:02 WAN Connection: WAN was restored.

Jul 23 15:40:03 WAN Connection: Ethernet link down.
Jul 23 15:40:19 WAN Connection: Ethernet link up.
Jul 23 15:40:27 WAN Connection: WAN was restored.

I really wonder what the problem is all about and how I can address it...

With kind regards
Joe

 

[RMerlin]

Hi,

Sorry to reopen this thread, but I have the same issue.

What I did so far is:
- Changing cable between Router and Modem (running with Cat 5e and Cat 6 cables)
- Changing the WAN MAC address of the router to get a new IP address from my ISP
- Reseting the router and cable modem (>30 Min. power off)
- Tried WAN DHCP (lease time was 7 days!) vs. fixed IP settings
But nothing changed or helped to overcome the WLAN connection going down!

As you can see the WAN link goes quite regular down (every ~6-7 hours) and comes backup up after some seconds:

Jul 18 00:21:37 WAN Connection: Ethernet link down.
Jul 18 00:21:48 WAN Connection: Ethernet link up.
Jul 18 00:21:56 WAN Connection: WAN was restored.

Jul 18 07:56:34 WAN Connection: Ethernet link down.
Jul 18 07:56:45 WAN Connection: Ethernet link up.
Jul 18 07:56:53 WAN Connection: WAN was restored.
[/QUOTE]

The last person who reported having that problem turned out to have a defective modem that kept rebooting itself randomly.  I would check that route.

 

[joegreat]

The last person who reported having that problem turned out to have a defective modem that kept rebooting itself randomly. I would check that route.

Hi,

OK, I was already thinking into this direction. Now I will go into the fight with my ISP to check that route of resolution...

With kind regards
Joe

 

[randomname00]

Hello, thank you for sharing your experiences. There is some comfort in knowing you aren't the only one having this issue.

Like many who have posted, I am getting the same message "ISP's DHCP did not function properly."

ISP: Charter.net
Cable Modem: Motorola SB6121 (Purchased March 2012)
Router: Asus RT-N66U (Purchased March 2012) FW: 3.0.0.4.370_172
Network Cable: Cat 6


For me, the disconnects started happening with the last two versions of Firmware. When the disconnects happen (usually one a day as of late), I login to the router, turn the WAN port off, then reboot the modem and re-enable the WAN port (does the trick each time... if I do not turn the WAN port off before rebooting, it won't work). Another option is to physically disconnect the WAN port from the Cable Modem before rebooting.

I put a ticket into Asus, but they told me the router needs to be sent back for repair. I doubt it is a hardware issue. I am going to dig up an older firmware and see what happens.

I have used various Linksys, D-Link, Xincom routers in the past without this issue. I like ASUS products, which is why I decided to try their router. I hope this issue can be resolved without laying out more money.

Version 3.0.0.4.372_1393 of the Asus firmware has proven to be more robust at recovering when the internet goes down (no longer need to reboot the router with the WAN disabled)

 

[Agent0071]

Cisco DPC 3010 Modem (rented)
Asus RT-AC66U
Charter Cable
Using Cable that came with the router (it is labeled Cat5e)
3.0.0.4.374_726

Common Message: WAN Connection: ISP's DHCP did not function properly.

I too get disconnects constantly. Every few minutes now for les than a minute and then reconnects. I upgraded to the

newest Asus firmaware, but the problem persists. Wifi says I am connected, but no connection to the internet.

Log Excerpt:

Nov 17 10:02:50 WAN Connection: WAN was restored.
Nov 17 10:12:40 WAN Connection: Ethernet link down.
Nov 17 10:12:40 stop_nat_rules: apply the redirect_rules!
Nov 17 10:12:50 WAN Connection: Ethernet link up.
Nov 17 10:12:50 rc_service: wanduck 288:notify_rc restart_wan_if 0
Nov 17 10:12:50 stop_wan(): perform DHCP release
Nov 17 10:12:50 dnsmasq[301]: read /etc/hosts - 5 addresses
Nov 17 10:12:50 dnsmasq[301]: using nameserver 24.247.24.53#53
Nov 17 10:12:50 dnsmasq[301]: using nameserver 24.159.64.23#53
Nov 17 10:12:50 dnsmasq[301]: using nameserver 66.189.0.100#53
Nov 17 10:12:50 dnsmasq[301]: read /etc/hosts - 5 addresses
Nov 17 10:12:50 dnsmasq[301]: using nameserver 24.247.24.53#53
Nov 17 10:12:50 dnsmasq[301]: using nameserver 24.159.64.23#53
Nov 17 10:12:50 dnsmasq[301]: using nameserver 66.189.0.100#53
Nov 17 10:12:50 kernel: br0: port 1(vlan1) entering disabled state
Nov 17 10:12:50 kernel: br0: port 1(vlan1) entering listening state
Nov 17 10:12:50 kernel: br0: port 1(vlan1) entering learning state
Nov 17 10:12:50 dnsmasq[301]: read /etc/hosts - 5 addresses
Nov 17 10:12:50 kernel: br0: topology change detected, propagating
Nov 17 10:12:50 kernel: br0: port 1(vlan1) entering forwarding state
Nov 17 10:12:51 WAN Connection: ISP's DHCP did not function properly.
Nov 17 10:12:51 dnsmasq[301]: read /etc/hosts - 5 addresses
Nov 17 10:12:51 dnsmasq[301]: using nameserver 192.168.100.1#53
Nov 17 10:12:51 start_nat_rules: apply the nat_rules(/tmp/nat_rules_eth0_eth0)!
Nov 17 10:12:51 rc_service: udhcpc 630:notify_rc stop_upnp
Nov 17 10:12:51 miniupnpd[616]: received signal 15, good-bye
Nov 17 10:12:51 rc_service: udhcpc 630:notify_rc start_upnp
Nov 17 10:12:51 syslog: SNet version started
Nov 17 10:12:51 miniupnpd[659]: HTTP listening on port 50195
Nov 17 10:12:51 miniupnpd[659]: Listening for NAT-PMP traffic on port 5351
Nov 17 10:12:51 dhcp client: bound 192.168.100.10 via 192.168.100.1 during 30 seconds.
Nov 17 10:12:56 WAN Connection: WAN was restored.
Nov 17 10:13:31 WAN Connection: Ethernet link down.
Nov 17 10:13:31 stop_nat_rules: apply the redirect_rules!
Nov 17 10:13:34 dnsmasq[301]: read /etc/hosts - 5 addresses
Nov 17 10:13:34 dnsmasq[301]: using nameserver 192.168.100.1#53
Nov 17 10:13:38 WAN Connection: Ethernet link up.
Nov 17 10:13:38 rc_service: wanduck 288:notify_rc restart_wan_if 0
Nov 17 10:13:38 stop_wan(): perform DHCP release
Nov 17 10:13:38 dnsmasq[301]: read /etc/hosts - 5 addresses
Nov 17 10:13:38 kernel: br0: port 1(vlan1) entering disabled state
Nov 17 10:13:38 dnsmasq[301]: using nameserver 192.168.100.1#53
Nov 17 10:13:38 kernel: br0: port 1(vlan1) entering listening state
Nov 17 10:13:38 kernel: br0: port 1(vlan1) entering learning state
Nov 17 10:13:38 kernel: br0: topology change detected, propagating
Nov 17 10:13:38 kernel: br0: port 1(vlan1) entering forwarding state
Nov 17 10:13:40 dnsmasq[301]: read /etc/hosts - 5 addresses
Nov 17 10:13:40 dnsmasq[301]: read /etc/hosts - 5 addresses
Nov 17 10:13:40 dnsmasq[301]: using nameserver 24.247.24.53#53
Nov 17 10:13:40 dnsmasq[301]: using nameserver 24.159.64.23#53
Nov 17 10:13:40 dnsmasq[301]: using nameserver 66.189.0.100#53
Nov 17 10:13:40 start_nat_rules: apply the nat_rules(/tmp/nat_rules_eth0_eth0)!
Nov 17 10:13:40 rc_service: udhcpc 669:notify_rc stop_upnp
Nov 17 10:13:40 miniupnpd[659]: received signal 15, good-bye
Nov 17 10:13:40 rc_service: udhcpc 669:notify_rc start_upnp
Nov 17 10:13:40 syslog: SNet version started
Nov 17 10:13:40 miniupnpd[698]: HTTP listening on port 51148
Nov 17 10:13:40 miniupnpd[698]: Listening for NAT-PMP traffic on port 5351
Nov 17 10:13:40 dhcp client: bound 24.151.26.226 via 24.151.26.1 during 26288 seconds.
Nov 17 10:13:46 WAN Connection: WAN was restored.
Nov 17 10:29:26 WAN Connection: Ethernet link down.
Nov 17 10:29:26 stop_nat_rules: apply the redirect_rules!
Nov 17 10:29:41 WAN Connection: Ethernet link up.
Nov 17 10:29:41 rc_service: wanduck 288:notify_rc restart_wan_if 0
Nov 17 10:29:41 stop_wan(): perform DHCP release
Nov 17 10:29:41 dnsmasq[301]: read /etc/hosts - 5 addresses
Nov 17 10:29:41 dnsmasq[301]: using nameserver 24.247.24.53#53
Nov 17 10:29:41 dnsmasq[301]: using nameserver 24.159.64.23#53
Nov 17 10:29:41 dnsmasq[301]: using nameserver 66.189.0.100#53
Nov 17 10:29:41 dnsmasq[301]: read /etc/hosts - 5 addresses
Nov 17 10:29:41 dnsmasq[301]: using nameserver 24.247.24.53#53
Nov 17 10:29:41 dnsmasq[301]: using nameserver 24.159.64.23#53
Nov 17 10:29:41 dnsmasq[301]: using nameserver 66.189.0.100#53
Nov 17 10:29:41 kernel: br0: port 1(vlan1) entering disabled state
Nov 17 10:29:41 kernel: br0: port 1(vlan1) entering listening state
Nov 17 10:29:41 kernel: br0: port 1(vlan1) entering learning state
Nov 17 10:29:41 kernel: br0: topology change detected, propagating
Nov 17 10:29:41 kernel: br0: port 1(vlan1) entering forwarding state
Nov 17 10:29:41 dnsmasq[301]: read /etc/hosts - 5 addresses
Nov 17 10:29:43 dnsmasq[301]: read /etc/hosts - 5 addresses
Nov 17 10:29:43 dnsmasq[301]: using nameserver 192.168.100.1#53
Nov 17 10:29:43 start_nat_rules: apply the nat_rules(/tmp/nat_rules_eth0_eth0)!
Nov 17 10:29:43 rc_service: udhcpc 712:notify_rc stop_upnp
Nov 17 10:29:43 miniupnpd[698]: received signal 15, good-bye
Nov 17 10:29:43 rc_service: udhcpc 712:notify_rc start_upnp
Nov 17 10:29:43 syslog: SNet version started
Nov 17 10:29:43 miniupnpd[741]: HTTP listening on port 43564
Nov 17 10:29:43 miniupnpd[741]: Listening for NAT-PMP traffic on port 5351
Nov 17 10:29:43 dhcp client: bound 192.168.100.10 via 192.168.100.1 during 30 seconds.
Nov 17 10:29:47 WAN Connection: WAN was restored.
Nov 17 10:30:17 WAN Connection: Ethernet link down.
Nov 17 10:30:17 stop_nat_rules: apply the redirect_rules!
Nov 17 10:30:22 WAN Connection: Ethernet link up.
Nov 17 10:30:22 rc_service: wanduck 288:notify_rc restart_wan_if 0
Nov 17 10:30:23 stop_wan(): perform DHCP release
Nov 17 10:30:23 dnsmasq[301]: read /etc/hosts - 5 addresses
Nov 17 10:30:23 kernel: br0: port 1(vlan1) entering disabled state
Nov 17 10:30:23 kernel: br0: port 1(vlan1) entering listening state
Nov 17 10:30:23 dnsmasq[301]: using nameserver 192.168.100.1#53
Nov 17 10:30:23 dnsmasq[301]: read /etc/hosts - 5 addresses
Nov 17 10:30:23 dnsmasq[301]: using nameserver 192.168.100.1#53
Nov 17 10:30:23 kernel: br0: port 1(vlan1) entering learning state
Nov 17 10:30:23 kernel: br0: topology change detected, propagating
Nov 17 10:30:23 kernel: br0: port 1(vlan1) entering forwarding state
Nov 17 10:30:23 dnsmasq[301]: read /etc/hosts - 5 addresses
Nov 17 10:30:23 dnsmasq[301]: read /etc/hosts - 5 addresses
Nov 17 10:30:23 dnsmasq[301]: using nameserver 24.247.24.53#53
Nov 17 10:30:23 dnsmasq[301]: using nameserver 24.159.64.23#53
Nov 17 10:30:23 dnsmasq[301]: using nameserver 66.189.0.100#53
Nov 17 10:30:23 start_nat_rules: apply the nat_rules(/tmp/nat_rules_eth0_eth0)!
Nov 17 10:30:23 rc_service: udhcpc 750:notify_rc stop_upnp
Nov 17 10:30:23 miniupnpd[741]: received signal 15, good-bye
Nov 17 10:30:23 rc_service: udhcpc 750:notify_rc start_upnp
Nov 17 10:30:23 syslog: SNet version started
Nov 17 10:30:23 miniupnpd[779]: HTTP listening on port 54460
Nov 17 10:30:23 miniupnpd[779]: Listening for NAT-PMP traffic on port 5351
Nov 17 10:30:23 dhcp client: bound 24.151.26.226 via 24.151.26.1 during 25285 seconds.
Nov 17 10:30:23 WAN Connection: WAN was restored.
Nov 17 10:31:38 dnsmasq-dhcp[301]: DHCPREQUEST(br0) 192.168.1.32 00:25:d3:3e:31:90
Nov 17 10:31:38 dnsmasq-dhcp[301]: DHCPACK(br0) 192.168.1.32 00:25:d3:3e:31:90 Sandie-PC
Nov 17 10:31:47 dnsmasq-dhcp[301]: DHCPINFORM(br0) 192.168.1.32 00:25:d3:3e:31:90
Nov 17 10:31:47 dnsmasq-dhcp[301]: DHCPACK(br0) 192.168.1.32 00:25:d3:3e:31:90 Sandie-PC
Nov 17 10:34:40 dnsmasq-dhcp[301]: DHCPINFORM(br0) 192.168.1.32 00:25:d3:3e:31:90
Nov 17 10:34:40 dnsmasq-dhcp[301]: DHCPACK(br0) 192.168.1.32 00:25:d3:3e:31:90 Sandie-PC
Nov 17 10:40:38 dnsmasq-dhcp[301]: DHCPDISCOVER(br0) 192.168.1.11 58:67:1a:ee:14:22
Nov 17 10:40:38 dnsmasq-dhcp[301]: DHCPOFFER(br0) 192.168.1.11 58:67:1a:ee:14:22
Nov 17 10:40:38 dnsmasq-dhcp[301]: DHCPREQUEST(br0) 192.168.1.11 58:67:1a:ee:14:22
Nov 17 10:40:38 dnsmasq-dhcp[301]: DHCPACK(br0) 192.168.1.11 58:67:1a:ee:14:22 nook-aa6bb8ae-38
Nov 17 12:09:49 dnsmasq-dhcp[301]: DHCPINFORM(br0) 192.168.1.32 00:25:d3:3e:31:90
Nov 17 12:09:49 dnsmasq-dhcp[301]: DHCPACK(br0) 192.168.1.32 00:25:d3:3e:31:90 Sandie-PC
Nov 17 12:14:48 dnsmasq-dhcp[301]: DHCPINFORM(br0) 192.168.1.32 00:25:d3:3e:31:90
Nov 17 12:14:48 dnsmasq-dhcp[301]: DHCPACK(br0) 192.168.1.32 00:25:d3:3e:31:90 Sandie-PC
Nov 17 12:31:48 dnsmasq-dhcp[301]: DHCPINFORM(br0) 192.168.1.32 00:25:d3:3e:31:90
Nov 17 12:31:48 dnsmasq-dhcp[301]: DHCPACK(br0) 192.168.1.32 00:25:d3:3e:31:90 Sandie-PC
Nov 17 12:40:20 miniupnpd[779]: Expired NAT-PMP mapping port 61601 UDP removed
Nov 17 12:40:20 miniupnpd[779]: Expired NAT-PMP mapping port 61601 TCP removed
Nov 17 12:43:02 dnsmasq-dhcp[301]: DHCPINFORM(br0) 192.168.1.32 00:25:d3:3e:31:90
Nov 17 12:43:02 dnsmasq-dhcp[301]: DHCPACK(br0) 192.168.1.32 00:25:d3:3e:31:90 Sandie-PC

 

[CooCooCaChoo]

How about your modem's log? How is the strength of the signal coming into the modem?

 

[Agent0071]

Here is the log. not sure what any of it means though.

About:


Model: Cisco DPC3010
Vendor: Cisco
Hardware Revision: 1.0

Bootloader Revision: 2.3.0_R1
Current Software Revision: d3000-v302r125554-120725a
Firmware Name: d3000-v302r125554-120725a.bin
Firmware Build Time: Jul 26 12:05:30 2012
Cable Modem Status: Operational


Cable Modem State:
DOCSIS Downstream Scanning: Completed
DOCSIS Ranging: Completed
DOCSIS DHCP: Completed
DOCSIS TFTP: Completed
DOCSIS Data Reg Complete: Completed
DOCSIS Privacy: Enabled

Downstream:
Power Level: Signal to Noise Ratio:
Channel 1: 1.0 dBmV 38.6 dB
Channel 2: 0.9 dBmV 38.2 dB
Channel 3: 1.4 dBmV 38.5 dB
Channel 4: 1.2 dBmV 38.4 dB
Channel 5: 0.0 dBmV 0.0 dB
Channel 6: 0.0 dBmV 0.0 dB
Channel 7: 0.0 dBmV 0.0 dB
Channel 8: 0.0 dBmV 0.0 dB

Upstream:
Power Level:
Channel 1: 42.0 dBmV
Channel 2: 0.0 dBmV
Channel 3: 0.0 dBmV
Channel 4: 0.0 dBmV

 

[Agent0071]

More logs if it helps. I am not sure what to do, but it makes streaming content difficult.

Nov 18 07:56:35 WAN Connection: Ethernet link down.
Nov 18 07:56:35 stop_nat_rules: apply the redirect_rules!
Nov 18 07:57:32 WAN Connection: Ethernet link up.
Nov 18 07:57:32 rc_service: wanduck 288:notify_rc restart_wan_if 0
Nov 18 07:57:33 stop_wan(): perform DHCP release
Nov 18 07:57:33 dnsmasq[301]: read /etc/hosts - 5 addresses
Nov 18 07:57:33 dnsmasq[301]: using nameserver 24.247.24.53#53
Nov 18 07:57:33 dnsmasq[301]: using nameserver 24.159.64.23#53
Nov 18 07:57:33 dnsmasq[301]: using nameserver 66.189.0.100#53
Nov 18 07:57:33 kernel: br0: port 1(vlan1) entering disabled state
Nov 18 07:57:33 kernel: br0: port 1(vlan1) entering listening state
Nov 18 07:57:33 kernel: br0: port 1(vlan1) entering learning state
Nov 18 07:57:33 kernel: br0: topology change detected, propagating
Nov 18 07:57:33 kernel: br0: port 1(vlan1) entering forwarding state
Nov 18 07:57:33 dnsmasq[301]: read /etc/hosts - 5 addresses
Nov 18 07:57:33 dnsmasq[301]: using nameserver 24.247.24.53#53
Nov 18 07:57:33 dnsmasq[301]: using nameserver 24.159.64.23#53
Nov 18 07:57:33 dnsmasq[301]: using nameserver 66.189.0.100#53
Nov 18 07:57:33 dnsmasq[301]: read /etc/hosts - 5 addresses
Nov 18 07:57:34 dnsmasq[301]: read /etc/hosts - 5 addresses
Nov 18 07:57:34 dnsmasq[301]: using nameserver 192.168.100.1#53
Nov 18 07:57:34 start_nat_rules: apply the nat_rules(/tmp/nat_rules_eth0_eth0)!
Nov 18 07:57:34 rc_service: udhcpc 3291:notify_rc stop_upnp
Nov 18 07:57:34 miniupnpd[3270]: received signal 15, good-bye
Nov 18 07:57:34 rc_service: udhcpc 3291:notify_rc start_upnp
Nov 18 07:57:34 syslog: SNet version started
Nov 18 07:57:34 dhcp client: bound 192.168.100.10 via 192.168.100.1 during 30 seconds.
Nov 18 07:57:34 miniupnpd[3320]: HTTP listening on port 49718
Nov 18 07:57:34 miniupnpd[3320]: Listening for NAT-PMP traffic on port 5351
Nov 18 07:57:38 WAN Connection: WAN was restored.
Nov 18 07:58:44 dnsmasq-dhcp[301]: DHCPREQUEST(br0) 192.168.1.239 cc:7e:e7:75:14:af
Nov 18 07:58:44 dnsmasq-dhcp[301]: DHCPACK(br0) 192.168.1.239 cc:7e:e7:75:14:af
Nov 18 08:00:48 WAN Connection: Ethernet link down.
Nov 18 08:00:48 stop_nat_rules: apply the redirect_rules!
Nov 18 08:00:52 WAN Connection: Ethernet link up.
Nov 18 08:00:52 rc_service: wanduck 288:notify_rc restart_wan_if 0
Nov 18 08:00:52 dnsmasq[301]: read /etc/hosts - 5 addresses
Nov 18 08:00:52 dnsmasq[301]: using nameserver 192.168.100.1#53
Nov 18 08:00:52 stop_wan(): perform DHCP release
Nov 18 08:00:52 dnsmasq[301]: read /etc/hosts - 5 addresses
Nov 18 08:00:52 dnsmasq[301]: using nameserver 192.168.100.1#53
Nov 18 08:00:52 kernel: br0: port 1(vlan1) entering disabled state
Nov 18 08:00:52 kernel: br0: port 1(vlan1) entering listening state
Nov 18 08:00:52 kernel: br0: port 1(vlan1) entering learning state
Nov 18 08:00:52 kernel: br0: topology change detected, propagating
Nov 18 08:00:52 kernel: br0: port 1(vlan1) entering forwarding state
Nov 18 08:00:54 dnsmasq[301]: read /etc/hosts - 5 addresses
Nov 18 08:00:54 dnsmasq[301]: read /etc/hosts - 5 addresses
Nov 18 08:00:54 dnsmasq[301]: using nameserver 24.247.24.53#53
Nov 18 08:00:54 dnsmasq[301]: using nameserver 24.159.64.23#53
Nov 18 08:00:54 dnsmasq[301]: using nameserver 66.189.0.100#53
Nov 18 08:00:54 start_nat_rules: apply the nat_rules(/tmp/nat_rules_eth0_eth0)!
Nov 18 08:00:54 rc_service: udhcpc 3345:notify_rc stop_upnp
Nov 18 08:00:54 miniupnpd[3320]: received signal 15, good-bye
Nov 18 08:00:54 rc_service: udhcpc 3345:notify_rc start_upnp
Nov 18 08:00:54 syslog: SNet version started
Nov 18 08:00:54 miniupnpd[3374]: HTTP listening on port 57902
Nov 18 08:00:54 miniupnpd[3374]: Listening for NAT-PMP traffic on port 5351
Nov 18 08:00:54 dhcp client: bound 24.151.26.226 via 24.151.26.1 during 18457 seconds.
Nov 18 08:00:55 WAN Connection: WAN was restored.
Nov 18 09:08:06 WAN Connection: Ethernet link down.
Nov 18 09:08:06 stop_nat_rules: apply the redirect_rules!
Nov 18 09:08:21 WAN Connection: Ethernet link up.
Nov 18 09:08:21 rc_service: wanduck 288:notify_rc restart_wan_if 0
Nov 18 09:08:21 dnsmasq[301]: read /etc/hosts - 5 addresses
Nov 18 09:08:21 dnsmasq[301]: using nameserver 24.247.24.53#53
Nov 18 09:08:21 dnsmasq[301]: using nameserver 24.159.64.23#53
Nov 18 09:08:21 dnsmasq[301]: using nameserver 66.189.0.100#53
Nov 18 09:08:21 stop_wan(): perform DHCP release
Nov 18 09:08:21 kernel: br0: port 1(vlan1) entering disabled state
Nov 18 09:08:21 dnsmasq[301]: read /etc/hosts - 5 addresses
Nov 18 09:08:21 dnsmasq[301]: using nameserver 24.247.24.53#53
Nov 18 09:08:21 dnsmasq[301]: using nameserver 24.159.64.23#53
Nov 18 09:08:21 dnsmasq[301]: using nameserver 66.189.0.100#53
Nov 18 09:08:21 kernel: br0: port 1(vlan1) entering listening state
Nov 18 09:08:21 kernel: br0: port 1(vlan1) entering learning state
Nov 18 09:08:21 kernel: br0: topology change detected, propagating
Nov 18 09:08:21 kernel: br0: port 1(vlan1) entering forwarding state
Nov 18 09:08:23 dnsmasq[301]: read /etc/hosts - 5 addresses
Nov 18 09:08:24 dnsmasq[301]: read /etc/hosts - 5 addresses
Nov 18 09:08:24 dnsmasq[301]: using nameserver 192.168.100.1#53
Nov 18 09:08:24 start_nat_rules: apply the nat_rules(/tmp/nat_rules_eth0_eth0)!
Nov 18 09:08:24 rc_service: udhcpc 3394:notify_rc stop_upnp
Nov 18 09:08:24 rc_service: udhcpc 3394:notify_rc start_upnp
Nov 18 09:08:24 rc_service: start_upnp is waitting stop_upnp...
Nov 18 09:08:24 miniupnpd[3374]: received signal 15, good-bye
Nov 18 09:08:25 dhcp client: bound 192.168.100.10 via 192.168.100.1 during 30 seconds.
Nov 18 09:08:25 syslog: SNet version started
Nov 18 09:08:25 miniupnpd[3423]: HTTP listening on port 40045
Nov 18 09:08:25 miniupnpd[3423]: Listening for NAT-PMP traffic on port 5351
Nov 18 09:08:29 WAN Connection: WAN was restored.
Nov 18 09:10:34 WAN Connection: Ethernet link down.
Nov 18 09:10:34 stop_nat_rules: apply the redirect_rules!
Nov 18 09:10:43 WAN Connection: Ethernet link up.
Nov 18 09:10:43 rc_service: wanduck 288:notify_rc restart_wan_if 0
Nov 18 09:10:43 stop_wan(): perform DHCP release
Nov 18 09:10:43 dnsmasq[301]: read /etc/hosts - 5 addresses
Nov 18 09:10:43 dnsmasq[301]: using nameserver 192.168.100.1#53
Nov 18 09:10:43 kernel: br0: port 1(vlan1) entering disabled state
Nov 18 09:10:43 kernel: br0: port 1(vlan1) entering listening state
Nov 18 09:10:43 kernel: br0: port 1(vlan1) entering learning state
Nov 18 09:10:43 kernel: br0: topology change detected, propagating
Nov 18 09:10:43 dnsmasq[301]: read /etc/hosts - 5 addresses
Nov 18 09:10:43 dnsmasq[301]: using nameserver 192.168.100.1#53
Nov 18 09:10:43 kernel: br0: port 1(vlan1) entering forwarding state
Nov 18 09:10:43 dnsmasq[301]: read /etc/hosts - 5 addresses
Nov 18 09:10:43 dnsmasq[301]: read /etc/hosts - 5 addresses
Nov 18 09:10:43 dnsmasq[301]: using nameserver 24.247.24.53#53
Nov 18 09:10:43 dnsmasq[301]: using nameserver 24.159.64.23#53
Nov 18 09:10:43 dnsmasq[301]: using nameserver 66.189.0.100#53
Nov 18 09:10:43 start_nat_rules: apply the nat_rules(/tmp/nat_rules_eth0_eth0)!
Nov 18 09:10:43 rc_service: udhcpc 3441:notify_rc stop_upnp
Nov 18 09:10:43 miniupnpd[3423]: received signal 15, good-bye
Nov 18 09:10:43 rc_service: udhcpc 3441:notify_rc start_upnp
Nov 18 09:10:43 syslog: SNet version started
Nov 18 09:10:43 miniupnpd[3470]: HTTP listening on port 48282
Nov 18 09:10:43 miniupnpd[3470]: Listening for NAT-PMP traffic on port 5351
Nov 18 09:10:43 dhcp client: bound 24.151.26.226 via 24.151.26.1 during 28800 seconds.
Nov 18 09:10:49 WAN Connection: WAN was restored.

 

[guipel]

After months without having any problems I updated to 3.0.0.4.374.34 (merlin) and the random disconnects returned.

A few minutes ago I was having a lot of disconnects.

Well, I changed the DHCP query frequency from normal to aggressive and the disconnections are occurring in minor frequencies.

I guess some DHCP issue on ISP are causing this. But with aggressive mode appears to give more stability. I will return with more info after doing more tests.

Merlin, could you add your guesses about that? If a DCHP request fails, it could be the reason many users are getting this issue? Is there a way to custom set the DHCP query frequency on cmdline in order to improve my tests?

 

[RMerlin]

Nov 18 09:10:34 WAN Connection: Ethernet link down.

This indicates that the network connection between the modem and the router goes down, then back up.

Nov 18 07:57:34 dhcp client: bound 192.168.100.10 via 192.168.100.1 during 30 seconds.

This indicate that your router obtained a lease from your modem itself rather than from your ISP.

The two together make me suspect that your modem is crashing and rebooting itself. See if you can catch the LED status on the modem when it happens. But most likely you will need to have the modem replaced.

 

[guipel]

Just a little update,

Technician from ISP come to my house today and found my cable modem was connected in a distant CMTS. He told me my connection was migrated because some contingency purpose but the system don't return the connection to a closer CMTS.

This was probably causing the issues. They already put me in a closer CMTS and the problem seems to be gone.

I think setting the DHCP Query to aggressive on some way make things better but definitely didn't solve the problem itself.

Best regards