Router restarts after big git push or big file upload

My problem is that modem (Modem / router #1 presented below) restarts itself, when I make git push with a lot of files (I'm not sure how big the push must be to break the connection, but smaller pushes with only a couple of files are working correctly). The same thing happens, when I'm connected with server via OpenVPN and I'm trying to upload a file through Samba.

Here's my home network setup (I have a home server exposed through ddns.net website):

Network setup

  1. PC is my home computer from which I'm sending requests. Its IP is random.
  2. PC is connected to Modem / router #1 via WiFi or LAN.
  3. Modem / router #1 also handles incoming requests - its public IP is used by ddns.net website. Its local IP is 192.168.0.1.
  4. Router #2 is connected to Modem / router #1. Its IP on Modem / router #1 is 192.168.0.103.
  5. Router #2 has its own local network, in which its IP is 192.168.1.1.
  6. Server is connected to Router #2 via LAN. Its IP is 192.168.1.100.
  7. ddns.net website requests go to Modem / router #1 and specific ports are forwarded to Router #2, which further forwards the request to Server, which finally handles the requests and sends a response the same way.
  8. Modem / router #1 model isn't easy to find, as it's just called "UPC Connect Box" (I'm from Poland and UPC is one of our ISPs), but I was able to find that it's software version is CH7465LG-NCIP-6.12.18.25-2p4-NOSH, which is used by Compal Broadband Networks CH7465LG-LC.
  9. Router #2 is TP-Link TL-WR841N.
  10. Server uses Lubuntu. lsb_release -a command returns:

No LSB modules are available.

Distributor ID: Ubuntu

Description: Ubuntu 18.04.2 LTS

Release: 18.04

Codename: bionic

  1. It's worth noting that such problems didn't happen in the past. I was able to upload files of any size on the exact same setup. I have no idea what could've changed.

Some things I've already tried / checked:

  1. PC connected to a mobile hotspot, instead of Modem / router #1 - in this case, everything works fine.
  2. PC connected to a Modem / router #1 via LAN instead of WiFi - the problem occurs in both cases.
  3. This solution from SO - doesn't change anything.
  4. I am able to see a log of Modem / router #1, which is unfortunately somewhat vague. When the restart happens, it simply states that "Cable Modem Reboot - due to power reset".
  5. Nothing wrong was found in server logs (at least in syslog and Samba logs).

I'm not expecting a ready solution for this problem, but I would really appreciate any advices on where can I start additional troubleshooting? What can I check to find out the cause of this behaviour?

-- Edit #1 --

I checked another possibility. When I'm connected directly to Router #2 via WiFi, it doesn't work as well. I must be completely outside my home network to make an upload. When I'm connected to Router #2, then it's still Modem / router #1 that resets itself.

-- Edit #2 --

Actually, after further analysis, check from Edit #1 doesn't really make sense, because it only adds another "node" to the request journey. I prepared a diagram of all three cases (PC connected to Modem / router #1 (UPC modem), Router #2 (TP-Link) and mobile hotspot). It may not be completely correct, it's really simplified, just to see how much work does the modem have.

Request diagram

-- Edit #3 --

Thanks to the diagram from Edit #2 I came to a conclusion, that I can try to reduce the work required by modem when I'm in the same network simply by accessing server by its local IP, instead of going through ddns domain. So when I pushed files to 192.168.0.103 (which is an IP of TP-Link router on UPC - see the first diagram), it was forwarded directly to the server, thus decreasing a load on UPC modem and everything worked flawlessly. Why more operations on the modem are causing it to reboot is still a mistery to me, especially knowing that it worked a couple of months ago, but at least I have a workaround for now. The main problem still remains though and I'm afraid it may actually be a firmware issue. Any new ideas are still welcome.

-- Edit #4 --

After switching a power adapter for a completely new one, router still resets when doing a big git push. This happens with and without a fan cooling it. I'll contact ISP.


It's faulty firmware, this did not happen with CH7465LG-NCIP-6.12.18.24-5p4-NOSH. This issue is causing router restart when hairpin or loopback is being performed. With this error, you cannot use public IP or domain name inside your local network, because that is what causes reboot. It is couple of month now and still not fixed. You can ask your ISP to remotely downgrade to CH7465LG-NCIP-6.12.18.24-5p4-NOSH but the router updates itself anyway and ISP cannot stop it from doing so, so we are all screwed.


You’ve made a well written, descriptive post. But, it’s written from the perspective that there must be something external to the modem causing the problem.

You wrote

I am able to see a log of Modem / router #1, which is unfortunately somewhat vague. When the restart happens, it simply states that "Cable Modem Reboot - due to power reset".

Nothing should ever cause a device to physically reset.

There are only three possible problems here:

  1. It’s hot and your modem is overheating. Increase air flow around the unit and test again. Put a fan directly on the unit.
  2. The modem or power adapter is bad. Get it replaced. It could be a firmware bug and you could ask the ISP to confirm that it is running the latest firmware, but I feel this is unlikely.
  3. Something is interrupting the power to the unit. Try a completely different outlet.

In my opinion, #1 is the most likely culprit and it may have already done irreversible damage requiring the modem to be replaced.

This is ISP equipment. You should be talking to them about why the modem is rebooting and then get it replaced if necessary.


I had the same problem: I was trying to reach out to my NAS via HTTPS and a dynamic DNS. When copying large files, the router restarted with a "power reset" message. Changing the addressing mode to local IP solved the problem.