本來有一個基於老毛子固件的小米路由器mini和聯想newifi D2，用着非常的穩定，後來由於一些變動，在光貓和路由器之間加了電力貓做穿牆，電力貓是騰達的200M，光纖是50M的普通家用光纖，電力貓跑滿帶寬問題不大
網絡拓撲如下圖，最初是光纖貓直連路由器，後來中間加入了電力貓
此時一直很穩定的老毛子固件就經常出現死機的情況，頻率很高，大約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下載，從來沒有出現過問題。
此時又懷疑是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變成了相距極遠的兩個網絡設備，所以上面一直在排查三層網絡的問題是沒用的，問題極有可能出現在二層網絡設備的信息交換上。
並且從現象上來看，在迅雷啓動P2P下載之後，RxPauseFrames馬上開始大量增長，只幾秒鐘時間就超過了沒有電力貓情況下把整個電影下載完的數值（相差幾十倍），而且增加的越來越快，直到電影下載16%的時候突然死機，迅雷如下圖，死機前的網卡情況如上圖
基於這一點懷疑，我在電力貓的子端和路由器之間加了一個TP-link的交換機，仍然由老毛子的路由器做PPPOE撥號，由於TP-link前面已經證實，不受電力貓的影響，對弱網情況下幀收發控制的很好。所以在加了這樣一層交換之後，電力貓吐出來的有問題的“髒幀”，或者大量的暫停幀（PauseFrames）就不會直接影響到OpenWrt的路由器，因爲在二層上路由器只會和距離極近的交換機進行通信，交換機連接電力貓端口產生的PauseFrames不會直接轉發給路由器。網絡拓撲圖如下
經過反覆測試，再也沒出現過死機的問題，而且WAN口RxPauseFrames的值非常小，直到一整部電影下載完才154，而路由器直連電力貓的情況下，下載到19%的時候就已經有5601，而且時間越長暫停幀會越多。下圖是增加了交換機之後的WAN口記錄
注：在加交換機和電力貓直連兩種情況下，連接電腦的LAN口TxPauseFrames和RxPauseFrames均爲0，也就是說在物理鏈路非常短而且穩定的情況下，PauseFrames和DropFrames應該都爲0纔對，數值越小代表鏈路越穩定。
於是問題解決之後，打消了我對老毛子固件不穩定的想法，現在對老毛子固件的穩定性還是依舊非常認可的，而且網上其他用戶對Padavan固件的穩定性口碑也是很好的，我指的是對於高併發大流量和許多第三方插件程序運行都沒有對CPU內存造成不利影響。由於Pandora Box固件也有同樣問題，所以連接電力貓之後導致網卡掛起的問題可能是OpenWrt的一個通病，現在手頭還沒有更多的OP系統來測試，但是解決方案就是不要讓OP路由器和電力貓直連，中間加一個交換機作爲緩衝，防止“髒幀”對路由器網卡產生不利的影響 。同時對於功能要求少而穩定性要求高的場合，使用非開源的商業路由系統，或者說叫原生系統穩定性會更強。