大 git push 或大文件上传后路由器重启

Bar*_*ski 20 router modem troubleshooting reboot upload

我的问题是调制解调器(下面显示的调制解调器 / 路由器 #1)会自动重启,当我制作git push大量文件时(我不确定要断开连接必须有多大的推力,但较小的推力只有几个文件工作正常)。当我通过 OpenVPN 与服务器连接并尝试通过 Samba 上传文件时,也会发生同样的事情。

这是我的家庭网络设置(我有一个通过 ddns.net 网站公开的家庭服务器):

网络设置

  1. PC是我的家用计算机,我从中发送请求。它的IP是随机的。
  2. PC通过 WiFi 或 LAN连接到调制解调器/路由器 #1
  3. 调制解调器/路由器 #1还处理传入请求 - ddns.net 网站使用其公共 IP。它的本地 IP 是 192.168.0.1。
  4. 路由器#2连接到调制解调器/路由器#1。它在调制解调器/路由器 #1上的 IP是 192.168.0.103。
  5. 路由器 #2有自己的本地网络,其 IP 为 192.168.1.1。
  6. 服务器通过 LAN连接到路由器 #2。它的 IP 是 192.168.1.100。
  7. ddns.net 网站请求转到调制解调器 / 路由器 #1,并将特定端口转发到路由器 #2路由器进一步将请求转发到服务器服务器最终以相同的方式处理请求并发送响应。
  8. 调制解调器/路由器 #1型号不容易找到,因为它只是被称为“UPC Connect Box”(我来自波兰,UPC 是我们的 ISP 之一),但我发现它的软件版本是CH7465LG-NCIP-6.12.18.25-2p4-NOSH,由仁宝宽带网络 CH7465LG-LC 使用。
  9. 路由器 #2是 TP-Link TL-WR841N。
  10. 服务器使用 Lubuntu。lsb_release -a命令返回:

没有可用的 LSB 模块。

分销商 ID: Ubuntu

描述:Ubuntu 18.04.2 LTS

发布: 18.04

代号:仿生

  1. 值得注意的是,过去没有发生过此类问题。我能够以完全相同的设置上传任何大小的文件。我不知道会发生什么变化。

我已经尝试/检查过的一些事情:

  1. PC连接到移动热点,而不是调制解调器/路由器 #1 - 在这种情况下,一切正常。
  2. PC通过 LAN 而不是 WiFi连接到调制解调器/路由器 #1 - 在这两种情况下都会出现问题。
  3. SO的这个解决方案- 不会改变任何东西。
  4. 我能够看到Modem / router #1的日志,不幸的是,这有点模糊。当重新启动时,它只是说明“电缆调制解调器重新启动 - 由于电源重置”。
  5. 在服务器日志中没有发现任何错误(至少在 syslog 和 Samba 日志中)。

我不希望有现成的解决方案来解决这个问题,但我真的很感激任何关于我可以从哪里开始额外故障排除的建议?我可以检查什么来找出这种行为的原因?

-- 编辑 #1 --

我检查了另一种可能性。当我通过 WiFi直接连接到路由器 #2 时,它也无法正常工作。我必须完全在我的家庭网络之外才能上传。当我连接到路由器 #2 时,它仍然是调制解调器/路由器 #1自行重置。

-- 编辑 #2 --

实际上,经过进一步分析,从 Edit #1 中检查并没有真正意义,因为它只是向请求旅程添加了另一个“节点”。我准备了所有三种情况的图表(PC 连接到调制解调器/路由器 #1(UPC 调制解调器)、路由器 #2(TP-Link)和移动热点)。它可能不完全正确,它确实简化了,只是为了看看调制解调器有多少工作。

请求图

-- 编辑 #3 --

感谢 Edit #2 中的图表,我得出一个结论,当我在同一网络中时,我可以尝试减少调制解调器所需的工作,只需通过其本地 IP 访问服务器,而不是通过 ddns 域。因此,当我将文件推送到 192.168.0.103(这是 UPC 上 TP-Link 路由器的 IP - 参见第一张图)时,它被直接转发到服务器,从而减少了 UPC 调制解调器的负载,并且一切正常。为什么调制解调器上的更多操作导致它重新启动对我来说仍然是个谜,尤其是知道它在几个月前可以工作,但至少我现在有一个解决方法。主要问题仍然存在,恐怕它实际上可能是固件问题。仍然欢迎任何新想法。

-- 编辑 #4 --

更换一个全新的电源适配器后,路由器在执行大 git push 时仍然重置。无论有没有风扇冷却都会发生这种情况。我会联系ISP。

App*_*ity 14

你写得很好,描述性的帖子。但是,它是从调制解调器的外部原因导致问题的角度编写的。

你写了

我能够看到调制解调器/路由器 #1 的日志,不幸的是,它有些模糊。当重新启动时,它只是说明“电缆调制解调器重新启动 - 由于电源重置”。

任何事情都不应该导致设备物理重置。

这里只有三个可能的问题:

  1. 天气很热,您的调制解调器过热。增加设备周围的气流并再次测试。将风扇直接放在设备上。
  2. 调制解调器或电源适配器损坏。换掉它。这可能是固件错误,您可以要求 ISP 确认它正在运行最新固件,但我觉得这不太可能。
  3. 某些东西正在中断设备的电源。尝试一个完全不同的插座。

在我看来,#1 是最有可能的罪魁祸首,它可能已经造成不可逆转的损坏,需要更换调制解调器。

这是ISP设备。你应该告诉他们关于为什么调制解调器重启,然后得到它取代,如果必要的。

  • 还有另一种可能。OP 发布的所有场景都是大型长寿命 TCP 连接。路由器固件中可能发生溢出。我很想看看 a) UDP 连接和 b) 大量小型 TCP 连接是否会发生类似的事情。例如,您可以使用 qBittorrent 对这两个场景进行负载测试。 (6认同)
  • @ user20574 为什么不呢?如果内核由于不可恢复的故障而死亡,它无法记录(因为路由器有很多可靠的持久存储),并且某种固件/看门狗电源循环主 SOC 以恢复,从微型发行版的角度来看,它确实“由于电源重置而重置”。 (5认同)
  • @BartłomiejZieliński 当它做更多的工作时它可能会变得更热,因为更多的数据正在通过它。 (2认同)
  • 如果是固件错误,ISP 可能会用另一个具有相同问题的调制解调器替换调制解调器。 (2认同)

小智 2

这是固件有问题,CH7465LG-NCIP-6.12.18.24-5p4-NOSH 没有发生这种情况。当执行发夹或环回时,此问题会导致路由器重新启动。出现此错误时,您无法在本地网络内使用公共 IP 或域名,因为这会导致重新启动。现在已经几个月了,还没修好。您可以要求您的 ISP 远程降级到 CH7465LG-NCIP-6.12.18.24-5p4-NOSH,但路由器无论如何都会自行更新,ISP 无法阻止它这样做,所以我们都完蛋了。