电力猫引起的OpenWrt路由器死机掉线的原因

矫情吗；* 2022-10-01 09:51 1084阅读 0赞

本来有一个基于老毛子固件的小米路由器mini和联想newifi D2，用着非常的稳定，后来由于一些变动，在光猫和路由器之间加了电力猫做穿墙，电力猫是腾达的200M，光纤是50M的普通家用光纤，电力猫跑满带宽问题不大

![20190612083041211.jpg][]     ![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x2c2hhb3Jvbmc_size_16_color_FFFFFF_t_70][]

网络拓扑如下图，最初是光纤猫直连路由器，后来中间加入了电力猫

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x2c2hhb3Jvbmc_size_16_color_FFFFFF_t_70 1][]

此时一直很稳定的老毛子固件就经常出现死机的情况，频率很高，大约1-2天就会死机一次，不得已打开了固件自带的定时重启功能，情况稍微好转了些。但是有一天我突然发现使用迅雷下载磁力链接的时候，并发数和下载速度都很快（4.1MB/s ），然后不用多久，也就十分钟左右就会出现死机的情况。

经过不停的重现死机，发现有如下规律

1、死机时下载速度都很快（4MB/s左右）如果只有几百K/s则不会死机

2、死机之前内存和CPU都没有占用过高的情况，相反，内存在下载前后几乎没有变化，CPU在满速下载时占用率为0.0

3、死机之前先是路由器后台无法访问，但此时下载和网上浏览都正常，然后不超过一分钟全面断网

4、在老毛子后台无法访问但下载仍然继续的时候，停止下载，马上路由器后台恢复正常访问

5、死机的时候2.4G和5G的wifi均不会断掉，未连入的设备可以正常的连入，也就是说CPU和内存以及无线设备实际上是没有死掉的，如果路由器能接显示器的话，应该能看到正常的后台。但此时ping任何地址都不通，类似于网卡发生故障。

7、死机之后，通过重启或者拔插一下WAN接口的网线马上就恢复正常，可以认为网卡故障只要断开WAN的网线就可以恢复正常。但是拔插LAN的网线没有作用。也就是说网卡的问题应该出在WAN接口上。正好和增加了电力猫的事实吻合。

8、死机之后由于拔掉WAN口网线即恢复正常，所以CPU，内存的记录都存在，系统日志也没有被清除，但是rsyslog没有在死机时和死机前没有任何相关日志。仅有pppoe echo失败和WAN口电缆拔掉的日志，更加印证了问题出在网卡上而非系统上。

此时我先怀疑可能是网络并发连接数的问题，于时从16384修改为65536。重新启动迅雷下载，问题依旧。而且观察情况来看，虽然P2P下载会产生非常多的UDP连接，但是最高也只有8000-9000，而且是昙花一现。所以并发连接数应该不是导致路由器死机的原因，而且之前用路由器的时候也经常P2P下载，从来没有出现过问题。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x2c2hhb3Jvbmc_size_16_color_FFFFFF_t_70 2][]此时又怀疑是NAT的问题，之前为了提高P2P下载的速度，我将路由器的NAT类型改为了Full Cone，而OpenWrt默认的NAT类型是Linux ipfilter组件的nat方式，也就是NAT 4。改会默认后死机问题依旧，排除NAT类型的问题。另外，在使用电力猫之前做P2P下载也是Full Cone，没有出现过问题，所以NAT导致死机应该不会成立。

然后我又怀疑是IPv4硬加速引起的问题，关闭硬件加速问题依旧。

后来怀疑可能是路由器过热或者体质的问题，但是不管使用newifi D2还是小米mini，都会出现一样的情况，甚至换了youku L2的Pandora Box固件也是一样的问题。所以估计应该是基于OpenWrt的固件都会存在这一问题。

最后换了一个普通的TP-link路由器，问题解决。看来非OP系统的路由器，在厂家多年的调校之下，稳定性要高于开源系统。这次的问题也刷新了我对开源系统和商业系统的认知。

在升级固件，降级固件，恢复出厂设置，关闭Adbyby等第三方软件等等测试中，均没有解决死机的问题。最后可以确定问题是出现在网卡上了。

虽然从过程上来看，是增加了电力猫之后才出现死机的问题，但是死机的毕竟不是电力猫，电力猫在路由器死机之后工作一切正常，而且如果是电力猫的问题不应该路由器连管理后台都进不去，所以还是应该在路由器上查找原因。

当我怀疑网卡驱动可能有问题的时候，想到这个路由器在其他地方使用更大的带宽下载都没有问题，所以不应该是网卡驱动的问题，一次偶然的情况，我发现在“网络信息”里面，WAN口的RxPauseFrames 数量特别大，正常来说在光猫的后面，一个十分小型的局域网内，是不应该有这么多丢帧的，但是由于电力猫使用的是电力线传输，虽然能跑满家庭宽带，但是干扰和波动肯定少不了，相当于一个小型的LAN变成了相距极远的两个网络设备，所以上面一直在排查三层网络的问题是没用的，问题极有可能出现在二层网络设备的信息交换上。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x2c2hhb3Jvbmc_size_16_color_FFFFFF_t_70 3][]

并且从现象上来看，在迅雷启动P2P下载之后，RxPauseFrames马上开始大量增长，只几秒钟时间就超过了没有电力猫情况下把整个电影下载完的数值（相差几十倍），而且增加的越来越快，直到电影下载16%的时候突然死机，迅雷如下图，死机前的网卡情况如上图

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x2c2hhb3Jvbmc_size_16_color_FFFFFF_t_70 4][]

## 解决方案一（仅做尝试）： ##

基于这一点怀疑，我在电力猫的子端和路由器之间加了一个TP-link的交换机，仍然由老毛子的路由器做PPPOE拨号，由于TP-link前面已经证实，不受电力猫的影响，对弱网情况下帧收发控制的很好。所以在加了这样一层交换之后，电力猫吐出来的有问题的“脏帧”，或者大量的暂停帧（PauseFrames）就不会直接影响到OpenWrt的路由器，因为在二层上路由器只会和距离极近的交换机进行通信，交换机连接电力猫端口产生的PauseFrames不会直接转发给路由器。网络拓扑图如下

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x2c2hhb3Jvbmc_size_16_color_FFFFFF_t_70 5][]

经过反复测试，再也没出现过死机的问题，而且WAN口RxPauseFrames的值非常小，直到一整部电影下载完才154，而路由器直连电力猫的情况下，下载到19%的时候就已经有5601，而且时间越长暂停帧会越多。下图是增加了交换机之后的WAN口记录

注：在加交换机和电力猫直连两种情况下，连接电脑的LAN口TxPauseFrames和RxPauseFrames均为0，也就是说在物理链路非常短而且稳定的情况下，PauseFrames和DropFrames应该都为0才对，数值越小代表链路越稳定。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x2c2hhb3Jvbmc_size_16_color_FFFFFF_t_70 6][]

通过长时间使用各种路由器，各种固件和原厂系统实验过后发现，不仅OP会出现这种问题，使用高恪固件一样会死机。也就是说这种情况不仅仅是固件的问题，路由器本身的设计也会导致状况的发生。罪魁祸首就是所谓的流控（Flow Control），在老毛子固件里简写成为FC，如下图中的 FC TX/RX 意思是该对端网络设备支持流控，并且使用发送和接受模式。即接受对方发来的暂停帧，我这边停止发送，也会向对端发送暂停帧，让对端慢点发送。

![2019061422253075.png][]

这里讲的流控是二层的流控，是由IEEE802.3协议规定的，不是路由器固件圈子里经常提到的3层4层的流控，即FC不是Qos，他们作用的层级不一样，本质上没有任何关联。

而OP和高恪固件对于流控处理的不好，一旦受到过多的暂停帧就会同时把WAN和LAN都挂起，并且没有任何日志输出，通过拔插LAN网线才能恢复。如果想从源头上解决这个问题，可以参考下面的方案二。

## 解决方法二（推荐）： ##

在经过一个星期的测试之后，发现上面那个方法有好几个不足之处：

1、对滤毒网络设备的要求比较高，上面成功的方案中使用的是TP-link的双频路由器（其4个LAN口可以作为一个交换机使用），是可以的，但是我在淘宝单独买了一个FAST的千兆交换机之后发现故障依旧，甚至路由器死机的时间都没有因为加了FAST交换机而改变，可以说是毫无用处了。

2、虽然使用了TP的交换机不会导致OP路由器死机了，但是下载速度一上去之后还是经常无法打开路由器后台，而且访问网页的时候也会经常碰到无故很慢很卡的情况。

3、增加了一台设备即增加了一个耗电，占用了弱电箱宝贵的空间，增加了串联系统的故障几率，还不一定所有的交换机都支持

所以经过不断实验，发现可以直接从二层流控FC上来解决这个问题。

方法非常简单粗暴，对于老毛子系统来说，进入左侧内部网络(LAN) - 以太网交换机，然后把WAN的流量控制从TX/RX改成TX（Asymmetric）或者Disabled即可，就去掉了二层流控的功能。如下图

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x2c2hhb3Jvbmc_size_16_color_FFFFFF_t_70 7][]

非常讽刺的是，这个二层流控FC本来的目的是为了减少三层IP协议的重传带来的延迟和损耗，所以新款的交换机基本都支持这个功能，只有一些老旧交换机没有这个功能，但实际上关闭之后迅雷P2P下载更快更稳定了，几乎没有什么网速波动，FC实际起到了一个反效果，如下图平稳光滑的速度曲线是关闭FC后获得的，开启FC不仅不光滑还会死机。。。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x2c2hhb3Jvbmc_size_16_color_FFFFFF_t_70 8][]

直接关闭FC之后马上解决了路由器会死机的问题，而且“网络信息”页面中，RxPauseFrames也一直保持0了，这一点充分印证了罪魁祸首就是二层流控。

![20190614223849499.png][]

并且该方案完全优于方案一，在高速下载时路由器后台也没有打不开的情况，平时也不会出现无故网速下降的情况，也无需定时重启路由器了。

## 解决方法三： ##

对于不能开启或关闭FC功能的固件，比如常见的高恪固件，我的小米mini刷入高恪后会和老毛子，潘多拉一样下载一会就死机，可以使用修改MTU的方法来解决。一般来说PPPoE的默认MTU时1492，但是我测试发现把MTU改为大包1500（不会影响下载速度），或者超小包500（会极大的影响下载速度）可以避免死机，其他值我没试。虽然改为1500会造成一些分包上的性能损耗，但是并不明显，可以防止死机。如下图

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x2c2hhb3Jvbmc_size_16_color_FFFFFF_t_70 9][]

问题解决之后，打消了我对老毛子固件不稳定的想法，现在对老毛子固件的稳定性还是依旧非常认可的，而且网上其他用户对Padavan固件的稳定性口碑也是很好的，我指的是对于高并发大流量和许多第三方插件程序运行都没有对CPU内存造成不利影响。由于Pandora Box固件也有同样问题，所以连接电力猫之后导致网卡挂起的问题可能是OpenWrt的一个通病。另外本次还印证了网络设备的两条真理

1、商业网络设备稳定性强于开源设备和系统

2、不同厂家的设备虽然遵守同一协议但是在对接时还是会出现问题

[20190612083041211.jpg]: https://img-blog.csdnimg.cn/20190612083041211.jpg
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x2c2hhb3Jvbmc_size_16_color_FFFFFF_t_70]: /images/20220118/65d6539dab2c41d6a09c7993c8abe598.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x2c2hhb3Jvbmc_size_16_color_FFFFFF_t_70 1]: /images/20220118/9362e4cb246b419ab079137e944dfc09.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x2c2hhb3Jvbmc_size_16_color_FFFFFF_t_70 2]: /images/20220118/e204c68fda964b8e8ee4a520df0bd797.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x2c2hhb3Jvbmc_size_16_color_FFFFFF_t_70 3]: /images/20220118/b0776f0151f14a23b066e9eb28b11c5d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x2c2hhb3Jvbmc_size_16_color_FFFFFF_t_70 4]: /images/20220118/976f36ed18fc4883ac51eddf2e4a057f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x2c2hhb3Jvbmc_size_16_color_FFFFFF_t_70 5]: /images/20220118/20de6cdc5b8b40cbab04750d5430ea99.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x2c2hhb3Jvbmc_size_16_color_FFFFFF_t_70 6]: /images/20220118/67525829b50b4f278774437556fb60de.png
[2019061422253075.png]: /images/20220118/b05ac83d472c496793df79ac97c2af90.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x2c2hhb3Jvbmc_size_16_color_FFFFFF_t_70 7]: /images/20220118/5fce75ca8a054ca1a6cb4cde4f599206.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x2c2hhb3Jvbmc_size_16_color_FFFFFF_t_70 8]: /images/20220118/ee3867d86e14412cb4d969b3b3dc9caa.png
[20190614223849499.png]: /images/20220118/95c11dddbd6e421886939780eea46c53.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x2c2hhb3Jvbmc_size_16_color_FFFFFF_t_70 9]: /images/20220118/8645a8e99f654acfbfd677c282bdea1b.png