DHCP stops working after a while

[Pyheme Guate]

Hi all,
I've recently updated by Cisco E3000 router for a ASUS RT-AC66U, now running Asuswrt-Merlin 380.57 firmware.
After a while playing with it and reading various posts on this forum, I was able to set it up, in the last few days, as I need it to work, including my OpenVPN client on the router and configure custom routes to use it as well as port forward to my ipcam on the router's LAN.

The ASUS router is connected on the WAN side to the ISP's issued modem on 192.168.0.0 subnet and issues IPs on the LAN side on the 192.168.2.0 subnet.

Just when I thought that I was all set, I noticed today that my PC was issued today an IP address from the ISP's modem (192.168.0.15). Connecting my cellphone, the same happened. Turning off the DHCP server on the ISP's modem resulted, as expected, in clients being unable to connect as no server provides them an IP to use. All machines with fixed IPs continue to work seamlessly.

Setting a fixed 192.168.2.xxx address in my PC gives me access to the ASUS router and to the Internet. Rebooting the ASUS router (from the reboot button in the admin panel) does not solve the problem.

Re-applying the DHCP settings does solve the problem, temporarily. It is the 2nd time that this happens to me. It seems to stop working after a day or so. The first time, I assumed I did something wrong as I was playing around was other settings. This time, I haven't touched the router for a couple of days and everything else seems to work.

I haven't seen any post regarding this problem. I am the only one to face this bug or is it really a 'user problem' caused by me not having seen an obvious setting somewhere?

Below are my LAN settings.

Thanks for any pointers that you could give me!

Pierre

 

[RMerlin]

Look at the system log for any error message.

 

[Pyheme Guate]

Hi RMerlin,

I forgot to mention that I went to check there but can't really find much useful info with respect to the DHCP server stopping or leases not being granted.
I'm pasting below the relevant logs in case you see something that I don't... It looks like the ASUS router offers an IP in the correct 2.0 range but the client requests one in the 0.0 range instead. What I can't explain is why the ASUS router forwards that request to the ISP's router instead of pushing an IP in the range that it handles.
(thinking better, the first time I had the issue, I was running the stock firmware).

LOG:
Feb 19 10:45:47 dnsmasq-dhcp[257]: DHCPDISCOVER(br0) XX:XX:XX:2b:e3:46
Feb 19 10:45:47 dnsmasq-dhcp[257]: DHCPOFFER(br0) 192.168.2.134 XX:XX:XX:2b:e3:46
Feb 19 10:45:47 dnsmasq-dhcp[257]: DHCPREQUEST(br0) 192.168.0.11 XX:XX:XX:2b:e3:46
Feb 19 10:45:47 dnsmasq-dhcp[257]: DHCPNAK(br0) 192.168.0.11 XX:XX:XX:2b:e3:46 wrong server-ID
Feb 19 10:45:47 kernel: DROP <4>DROP IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:XX:XX:XX:2b:e3:46:08:00 <1>SRC=192.168.0.11 DST=192.168.0.255 <1>LEN=96 TOS=0x00 PREC=0x00 TTL=128 ID=11127 PROTO=UDP <1>SPT=137 DPT=137 LEN=76 # THERE are many of these
[...]
Feb 19 10:46:48 dnsmasq-dhcp[257]: DHCPREQUEST(br0) 192.168.0.15 XX:XX:XX:2c:8f:68
Feb 19 10:46:48 dnsmasq-dhcp[257]: DHCPNAK(br0) 192.168.0.15 XX:XX:XX:2c:8f:68 wrong network
Feb 19 10:46:52 dnsmasq-dhcp[257]: DHCPDISCOVER(br0) XX:XX:XX:2c:8f:68
Feb 19 10:46:52 dnsmasq-dhcp[257]: DHCPOFFER(br0) 192.168.2.60 XX:XX:XX:2c:8f:68
Feb 19 10:46:52 dnsmasq-dhcp[257]: DHCPREQUEST(br0) 192.168.0.15 XX:XX:XX:2c:8f:68
Feb 19 10:46:52 dnsmasq-dhcp[257]: DHCPNAK(br0) 192.168.0.15 XX:XX:XX:2c:8f:68 wrong server-ID
[...]
# UPON 2 REBOOTS AND RE-APPLYING DHCP SETTINGS
Feb 19 11:10:00 rc_service: httpd 258:notify_rc restart_net_and_phy
Feb 19 11:10:02 FTP Server: daemon is stopped
Feb 19 11:10:02 Samba Server: smb daemon is stopped
Feb 19 11:10:02 dnsmasq[257]: exiting on receipt of SIGTERM
Feb 19 11:10:02 miniupnpd[704]: shutting down MiniUPnPd
Feb 19 11:10:03 kernel: Attempt to kill tasklet from interrupt
Feb 19 11:10:03 kernel: br0: port 1(vlan1) entering disabled state
Feb 19 11:10:03 kernel: vlan1: dev_set_promiscuity(master, 1)
[...]
Feb 19 11:10:16 dnsmasq-dhcp[917]: DHCPDISCOVER(br0) XX:XX:XX:c9:44:f8
Feb 19 11:10:16 dnsmasq-dhcp[917]: DHCPOFFER(br0) 192.168.2.82 XX:XX:XX:c9:44:f8
Feb 19 11:10:17 WAN Connection: ISP's DHCP did not function properly. # that's because I turned it off.
Feb 19 11:10:40 kernel: vlan1: received packet with own address as source address
Feb 19 11:10:40 dnsmasq-dhcp[917]: DHCPDISCOVER(br0) XX:XX:XX:c9:44:f8
Feb 19 11:10:40 dnsmasq-dhcp[917]: DHCPOFFER(br0) 192.168.2.82 XX:XX:XX:c9:44:f8
Feb 19 11:10:43 kernel: vlan1: received packet with own address as source address
Feb 19 11:10:43 dnsmasq-dhcp[917]: DHCPDISCOVER(br0) XX:XX:XX:c9:44:f8
Feb 19 11:10:43 dnsmasq-dhcp[917]: DHCPOFFER(br0) 192.168.2.82 XX:XX:XX:c9:44:f8
Feb 19 11:10:48 dnsmasq-dhcp[917]: DHCPREQUEST(br0) 192.168.0.15 XX:XX:XX:2c:8f:68
Feb 19 11:10:48 dnsmasq-dhcp[917]: DHCPNAK(br0) 192.168.0.15 XX:XX:XX:2c:8f:68 wrong network
Feb 19 11:10:52 dnsmasq-dhcp[917]: DHCPDISCOVER(br0) XX:XX:XX:2c:8f:68
Feb 19 11:10:52 dnsmasq-dhcp[917]: DHCPOFFER(br0) 192.168.2.60 XX:XX:XX:2c:8f:68
Feb 19 11:10:52 dnsmasq-dhcp[917]: DHCPREQUEST(br0) 192.168.2.60 XX:XX:XX:2c:8f:68
Feb 19 11:10:52 dnsmasq-dhcp[917]: DHCPACK(br0) 192.168.2.60 XX:XX:XX:2c:8f:68 android
Feb 19 11:11:06 kernel: vlan1: received packet with own address as source address
Feb 19 11:11:08 dnsmasq-dhcp[917]: DHCPDISCOVER(br0) XX:XX:XX:c9:44:f8
Feb 19 11:11:08 dnsmasq-dhcp[917]: DHCPOFFER(br0) 192.168.2.82 XX:XX:XX:c9:44:f8
Feb 19 11:11:08 dnsmasq-dhcp[917]: DHCPREQUEST(br0) 192.168.0.15 XX:XX:XX:2c:8f:68
Feb 19 11:11:08 dnsmasq-dhcp[917]: DHCPNAK(br0) 192.168.0.15 XX:XX:XX:2c:8f:68 wrong address
Feb 19 11:11:08 dnsmasq-dhcp[917]: DHCPREQUEST(br0) 192.168.0.15 XX:XX:XX:2c:8f:68
Feb 19 11:11:08 dnsmasq-dhcp[917]: DHCPNAK(br0) 192.168.0.15 XX:XX:XX:2c:8f:68 wrong address
Feb 19 11:11:08 kernel: vlan1: received packet with own address as source address
[...]

 

[RMerlin]

What I see here is normal. Let's take this exchange for example:

Feb 19 11:10:48 dnsmasq-dhcp[917]: DHCPREQUEST(br0) 192.168.0.15 XX:XX:XX:2c:8f:68
Feb 19 11:10:48 dnsmasq-dhcp[917]: DHCPNAK(br0) 192.168.0.15 XX:XX:XX:2c:8f:68 wrong network
Feb 19 11:10:52 dnsmasq-dhcp[917]: DHCPDISCOVER(br0) XX:XX:XX:2c:8f:68
Feb 19 11:10:52 dnsmasq-dhcp[917]: DHCPOFFER(br0) 192.168.2.60 XX:XX:XX:2c:8f:68
Feb 19 11:10:52 dnsmasq-dhcp[917]: DHCPREQUEST(br0) 192.168.2.60 XX:XX:XX:2c:8f:68
Feb 19 11:10:52 dnsmasq-dhcp[917]: DHCPACK(br0) 192.168.2.60 XX:XX:XX:2c:8f:68 android

This is an Android device who was previously connected to another wifi with an IP of 192.168.0.15. The device was moved home, where it requested a lease, and asked if it could keep using its existing lease. The DHCP properly rejects it (DHCPNAK) because it's from a different scope. The client asks for a new lease, which the router did provide (192.168.2.60), and your device accepted (DHCPACK).

 

[Pyheme Guate]

Exactly. So the logs that I can access (the copy above started with the oldest logs I have) don't seem to explain that problem that I'm facing.

Since the problem seems to occur after a certain time of activity, and knowing that DHCP is handled by dnsmasq, I'm considering as a possible 'temporary fix' setting up a cron job to restart dnsmasq every 8h or 10h. Does that seem like a bad idea? Would that mess up the handling of the leases?

Thanks.

 

[ColinTaylor]

What is the make and model number of your ISP-supplied modem?

From your description it sounds more like a (wireless?) router. Which would explain a lot.

 

[Pyheme Guate]

Yes, it is a (wireless) router RCA Thomson DCW725.
The ISP, Claro, gives a 10.xxx.xxx.xxx address on this router. It is used to access the net + phone + tv, so can't be removed from the equation.

The WiFi is disabled however and, now, so is the DHCP. The PCs are connected with cable though.

Why do you think this could be a problem?

 

[ColinTaylor]

Are you absolutely sure the wireless is turned off on the Thomson? It sounds like your clients might still be connecting to it. Change the SSID's and passwords on the ASUS to ensure that the clients can connect only to the ASUS.

Is the Thomson's 10.x.x.x address on its WAN or LAN side? You said earlier that it gave out a 192.168.0.x address.

What is plugged into the 4 LAN ports on the Thomson?

 

[Zirescu]

You should probably have the cable operator switch your DCW725 into Cable Modem only mode. Alternatively...

1. You'll want to disable the DCW725 DHCP server on the LAN page
2. Set at static IP address on the WAN page of the ASUS that is in the same IP range of the LAN on the DCW732 Ex. 192.168.0.2,
3. Set the Gateway address to that of the LAN IP of the DCW725 (192.168.0.1)
4. Setup the DNS records as applicable on the WAN side of the ASUS either what your ISP provides or OpenDNS/Google.
5. You'll probably want to enable the DMZ Host on the DCW725 to point to the Static IP address you setup on the WAN page of the ASUS (192.168.0.2).

Note: with this setup above you might lose connection to the DCW725 interface when connected behind the Asus.

 

[sfx2000]

Even when the CM is in modem mode, many will run with a built-in DHCP server if the WAN connection is lost...

Check to see what the scope is on the CM for DHCP - shouldn't matter in any event... but I'm wondering if your CM has connectivity issues which is causing some of your problem...

 

[Pyheme Guate]

Colin Taylor,
The 10.xx.xx.xx is the ip range on the WAN side (IP given by the ISP. I doubt there is a connection here with my problem though.

There's only 1 cable connected to the Thomson, that of the ASUS router.

I double checked, the WiFi was off on the WiFi setup page but there also was an option to turn it off elsewhere under tab "radio". I just turned it off there too.

However, this could have been the issue with the cellphones but more doubtful with the PC as none of the 2 has wifi adapters.

The DHCP is now off on the Thomson and the WAN of the Asus is set to a static IP. However, even like this, the ASUS would not give an IP to the PCS upon releasing/renewing the lease in Windows until I reset the DHCP settings (just clicking Apply without changing anything).

Zirescu,
Consider the ISP completely worthless so any option that has to do with asking them anything is pretty much dead by default.
I had the setup as you describe it before (with the Cisco router) but I changed the 4th or 5th time the ISP reset without warning the configuration of the Thomson (remotely) as part of their "troubleshooting" of a connectivity issue on the line (which ended up being, after dozebs of service calls, rotten connections on their external line coming to my house).
I'm not eager to get back to that configuration as every reset by the ISP results in 2 DHCP servers on the same range and a nightmare for me guiding my wife to make things work again over the phone...

Furthermore, if my issue really is what I think, that the DHCP server of the ASUS stops working after a while, I would end up with the same issue anyway, no?

Well, thanks to all for the help. It does confort me to see that it is an isolated incident and, therefore, most likely a configuration problem on my side.

I'll wait to see if the problem happens again having turned off the DHCP and Wi-Fi/Radio on the Thomson (the problem in that case being not receiving an IP rather than receiving one from the Thomson). If so, maybe a programmed reboot can help?!?

The odd part is that I've never had that issue in years of running with the same setup using 2 other routers instead of the ASUS...

 

[sfx2000]

now running Asuswrt-Merlin 380.57

The Asus 380 builds had a number of changes - when updating - did you do a full-on factory reset?

Could explain a lot of your concerns...

 

[ColinTaylor]

A quick question. You haven't disabled the firewall on the ASUS have you? Just checking.

 

[Pyheme Guate]

Turning off the router and then on while pressing the reset button?
Yes, I did.

But I do think that it could be a good idea to restart from scratch in case the problem persists!

 

[ColinTaylor]

But I do think that it could be a good idea to restart from scratch in case the problem persists!

I agree. Something strange is going on and in such cases a complete reset often fixes it.

No need to fiddle around with buttons, you can reset it from Administration > Restore/Save/Upload Setting.

Also, it's worth just doing the minimum configuration possible (leave everything at default settings, DHCP, etc.) and seeing if the problem is solved before doing further customisation (VPN, static IP's, etc.).

 

[A.D.]

Turning off the router and then on while pressing the reset button? Yes, I did.

In the context of my observations with 380, I was asked to follow this procedure: http://www.snbforums.com/threads/no...l-and-manual-configuration.27115/#post-205573

 

[debt]

I am having the same problem with my Asus AC68p. I am getting disconnected from the internet constantly. I can't remember if it started with the .57 or .58 firmware. I have reset to factory, flashed to previous firmware. My ISP is coming out Wednesday. They said my router disconnected from the modem like 67 times in a matter of hours. I was convinced it was a router issue but they are going to come out and check out the equipment on their end. They think it is their equipment. I think I have seen other people with the same issue in this forum but no one knows what it is. I'm still not convinced it is not a firmware issue. I have attached a section of my log. I am not very tech savvy; just enough to be dangerous. If anyone sees anything pop out, I would appreciate the input. Any information I can have the tech guy when he comes out might help.

May 14 07:08:57 WAN Connection: ISP's DHCP did not function properly.
May 14 07:09:31 rc_service: udhcpc 8464:notify_rc start_firewall
May 14 07:09:31 dnsmasq[431]: read /etc/hosts - 5 addresses
May 14 07:09:31 dnsmasq[431]: using nameserver 192.168.15.1#53 for domain lan
May 14 07:09:31 dnsmasq[431]: using nameserver 192.168.15.1#53
May 14 07:09:32 start_nat_rules: apply the nat_rules(/tmp/nat_rules_eth0_eth0)!
May 14 07:09:32 wan: finish adding multi routes
May 14 07:09:32 rc_service: udhcpc 8464:notify_rc stop_upnp
May 14 07:09:32 rc_service: waitting "start_firewall" via udhcpc ...
May 14 07:09:32 WAN Connection: WAN was restored.
May 14 07:09:33 rc_service: udhcpc 8464:notify_rc start_upnp
May 14 07:09:33 rc_service: waitting "stop_upnp" via udhcpc ...
May 14 07:09:33 miniupnpd[7651]: shutting down MiniUPnPd
May 14 07:09:34 miniupnpd[8498]: HTTP listening on port 51841
May 14 07:09:34 miniupnpd[8498]: Listening for NAT-PMP/PCP traffic on port 5351
May 14 07:09:37 rc_service: udhcpc 8464:notify_rc start_firewall
May 14 07:09:37 dhcp client: bound 192.168.15.8 via 192.168.15.1 during 86400 seconds.
May 14 07:09:38 start_nat_rules: apply the nat_rules(/tmp/nat_rules_eth0_eth0)!
May 14 07:10:12 WAN Connection: Ethernet link down.
May 14 07:10:12 stop_nat_rules: apply the redirect_rules!
May 14 07:10:17 WAN Connection: Ethernet link up.
May 14 07:10:17 rc_service: wanduck 422:notify_rc restart_wan_if 0
May 14 07:10:17 dnsmasq[431]: read /etc/hosts - 5 addresses
May 14 07:10:17 dnsmasq[431]: using nameserver 192.168.15.1#53 for domain lan
May 14 07:10:17 dnsmasq[431]: using nameserver 192.168.15.1#53
May 14 07:10:18 kernel: Attempt to kill tasklet from interrupt
May 14 07:10:18 kernel: br0: port 1(vlan1) entering forwarding state
May 14 07:10:18 miniupnpd[8498]: ioctl(s, SIOCGIFADDR, ...): Cannot assign requested address
May 14 07:10:18 miniupnpd[8498]: Failed to get IP for interface eth0
May 14 07:10:18 miniupnpd[8498]: SendNATPMPPublicAddressChangeNotification: cannot get public IP address, stopping
May 14 07:10:18 kernel: device eth0 left promiscuous mode
May 14 07:10:18 kernel: device eth0 entered promiscuous mode
May 14 07:10:18 kernel: br0: topology change detected, propagating
May 14 07:10:18 kernel: br0: port 1(vlan1) entering forwarding state
May 14 07:10:18 kernel: br0: port 1(vlan1) entering forwarding state
May 14 07:10:18 dnsmasq[431]: read /etc/hosts - 5 addresses
May 14 07:10:18 dnsmasq[431]: using nameserver 192.168.15.1#53 for domain lan
May 14 07:10:18 dnsmasq[431]: using nameserver 192.168.15.1#53
May 14 07:10:18 wan: mac clone: [wan0_hwaddr] == [b4:f2:e8:27:9a:e5]
May 14 07:10:18 dnsmasq[431]: read /etc/hosts - 5 addresses
May 14 07:10:23 WAN Connection: ISP's DHCP did not function properly.
May 14 07:10:38 WAN Connection: Ethernet link up.
May 14 07:10:38 rc_service: wanduck 422:notify_rc restart_wan_if 0
May 14 07:10:38 dnsmasq[431]: read /etc/hosts - 5 addresses
May 14 07:10:38 kernel: Attempt to kill tasklet from interrupt
May 14 07:10:39 kernel: br0: port 1(vlan1) entering forwarding state
May 14 07:10:39 kernel: device eth0 left promiscuous mode
May 14 07:10:39 kernel: device eth0 entered promiscuous mode
May 14 07:10:39 kernel: br0: topology change detected, propagating
May 14 07:10:39 kernel: br0: port 1(vlan1) entering forwarding state
May 14 07:10:39 kernel: br0: port 1(vlan1) entering forwarding state
May 14 07:10:41 wan: mac clone: [wan0_hwaddr] == [b4:f2:e8:27:9a:e5]
May 14 07:10:41 dnsmasq[431]: read /etc/hosts - 5 addresses
May 14 07:11:13 rc_service: udhcpc 8761:notify_rc start_firewall
May 14 07:11:13 dnsmasq[431]: read /etc/hosts - 5 addresses
May 14 07:11:13 dnsmasq[431]: using nameserver 192.168.15.1#53 for domain lan
May 14 07:11:13 dnsmasq[431]: using nameserver 192.168.15.1#53
May 14 07:11:14 start_nat_rules: apply the nat_rules(/tmp/nat_rules_eth0_eth0)!
May 14 07:11:14 wan: finish adding multi routes
May 14 07:11:14 rc_service: udhcpc 8761:notify_rc stop_upnp
May 14 07:11:14 rc_service: waitting "start_firewall" via udhcpc ...
May 14 07:11:15 rc_service: udhcpc 8761:notify_rc start_upnp
May 14 07:11:15 rc_service: waitting "stop_upnp" via udhcpc ...
May 14 07:11:15 miniupnpd[8498]: shutting down MiniUPnPd
May 14 07:11:16 WAN Connection: WAN was restored.
May 14 07:11:16 miniupnpd[8831]: HTTP listening on port 33477
May 14 07:11:16 miniupnpd[8831]: Listening for NAT-PMP/PCP traffic on port 5351
May 14 07:11:19 dnsmasq-dhcp[431]: DHCPREQUEST(br0) 192.168.1.37 dc:53:60:e9:3e:96
May 14 07:11:19 dnsmasq-dhcp[431]: DHCPACK(br0) 192.168.1.37 dc:53:60:e9:3e:96 Debra
May 14 07:11:19 dnsmasq-dhcp[431]: DHCPREQUEST(br0) 192.168.1.37 dc:53:60:e9:3e:96
May 14 07:11:19 dnsmasq-dhcp[431]: DHCPACK(br0) 192.168.1.37 dc:53:60:e9:3e:96 Debra
May 14 07:11:20 rc_service: udhcpc 8761:notify_rc start_firewall
May 14 07:11:20 dhcp client: bound 192.168.15.8 via 192.168.15.1 during 86400 seconds.
May 14 07:11:20 start_nat_rules: apply the nat_rules(/tmp/nat_rules_eth0_eth0)!
May 14 07:12:05 miniupnpd[8831]: upnp_event_process_notify: connect(192.168.1.37:2869): Connection timed out
May 14 07:12:05 miniupnpd[8831]: upnp_event_process_notify: connect(192.168.1.37:2869): Connection timed out
May 14 07:12:06 miniupnpd[8831]: upnp_event_process_notify: connect(192.168.1.37:2869): Connection timed out
May 14 07:12:08 miniupnpd[8831]: upnp_event_process_notify: connect(192.168.1.37:2869): Connection timed out
May 14 07:12:08 miniupnpd[8831]: upnp_event_process_notify: connect(192.168.1.37:2869): Connection timed out
May 14 07:12:08 miniupnpd[8831]: upnp_event_process_notify: connect(192.168.1.37:2869): Connection timed out
May 14 07:13:11 WAN Connection: Ethernet link down.
May 14 07:13:11 stop_nat_rules: apply the redirect_rules!
May 14 07:13:17 WAN Connection: Ethernet link up.
May 14 07:13:17 rc_service: wanduck 422:notify_rc restart_wan_if 0
May 14 07:13:17 dnsmasq[431]: read /etc/hosts - 5 addresses
May 14 07:13:17 dnsmasq[431]: using nameserver 192.168.15.1#53 for domain lan
May 14 07:13:17 dnsmasq[431]: using nameserver 192.168.15.1#53
May 14 07:13:17 kernel: Attempt to kill tasklet from interrupt
May 14 07:13:17 kernel: br0: port 1(vlan1) entering forwarding state
May 14 07:13:17 miniupnpd[8831]: ioctl(s, SIOCGIFADDR, ...): Cannot assign requested address
May 14 07:13:17 miniupnpd[8831]: Failed to get IP for interface eth0
May 14 07:13:17 miniupnpd[8831]: SendNATPMPPublicAddressChangeNotification: cannot get public IP address, stopping
med out

 

[L&LD]

After flashing to a new firmware version have you ever performed a minimal and manual configuration after resetting the router to factory defaults?

http://www.snbforums.com/threads/no...l-and-manual-configuration.27115/#post-205573


The above should be done before your ISP techs come out.

Along with turning off all network equipment (including modem) and physically unplugging them from the AC power for at least 30 minutes (ideally an hour or more) before turning it on again in this order.

Plug in Modem (wait 5 minutes).
Plug in Router (wait 5 minutes).
Plug in any switches you may have.
Turn on your wired clients (computers, NAS, etc.).
Turn on your wireless clients.

Monitor your modem and router to see if the issue persists.

 

[RMerlin]

May 14 07:10:12 WAN Connection: Ethernet link down.

Your modem is most likely crashing/rebooting itself. Nothing to do with the router or the firmware, the Ethernet connection between the modem and the router completely disconnects.

 

[debt]

Your modem is most likely crashing/rebooting itself. Nothing to do with the router or the firmware, the Ethernet connection between the modem and the router completely disconnects.

Thanks Merlin. The ISP is coming out tomorrow to replace the modem and cables.