关于使用Lean大神源码编译R7500V2固件不稳问题（ksoftirqd高占用）的分析

b***

关于使用Lean大神源码编译R7500V2固件不稳问题（ksoftirqd高占用）的分析

由于以前一直用R4.4的LEDE已经3年没更新了，想更新一下新版的LEDE/OP，然而搜索了很久发现没有新的第三方固件出来，因此决定用Lean大神源码自己编译一个用一下，因为是第一次操作，编译过程就不再班门弄斧，反正克服各种问题后终于顺利完成（由于标题所列原因实际上是编译了好几个版本），最终版在Lean大神默认配置项下增加了USB打印、可道云、FRPC、访客网络和Adblock几项，删除了nlbwmon，原本加上的mwan3也删除了。

分析排错过程如下：
1、在新固件刷入后1-2天后遇到ping值高并丢包情况，且反复出现。ssh上去，top一下，发现ksoftirqd/1占用高，从1x%-4x%，通过重启不能解决问题，重置配置后重新手动设置似乎能恢复一段时间，导入配置无效会立马出现相同的状况。之后用cat /proc/interrupts，排查到Function call interrupts把软中断资源耗尽，但继续深入查Function call interrupts到底是哪个进程导致的无果。

2、继续排查日志，发现：

2.1 kern.notice kernel: [66659.713290] nf_ct_snmp_trap: dropping packet: parser failed
kern.notice kernel: [66659.713290]  IN= OUT= SRC=xx.xx.xx.xx DST=yy.yy.yy.yy LEN=58 TOS=0x00 PREC=0x00 TTL=127 ID=22318 PROTO=UDP SPT=10723 DPT=162 LEN=38
这样的日志出现一大堆，系统日志和内核日志都有报，且时间上和ksoftirqd变化有一定的关联性。说明：yy.yy.yy.yy会变化，最终找出以下5组ip。
193.113.250.49
192.113.183.113
192.113.249.177
192.114.249.179
193.114.250.51
防火墙中设规则禁出，但日志依然还是会报。
这几个IP分布具有一定规律性，至今不清楚是哪个包引起的。但出现该日志时网络肯定会有抖动，虽然最终排除了其直接引发ksoftirqd占用高，但心里依然对这几个IP存疑，不知道有没有哪位大神给我释疑一下，谢谢。

2.2 daemon.err nlbwmon[15514]: Too many pending MAC address lookups
也是一次重复出现过多条，会引起ksoftirqd占用，对该报错进行追查，发现该提示存在“nfnetlink.c”(https://github.com/jow-/nlbwmon/blob/master/nfnetlink.c)中，与数据库记录条数有关。然后发现是因为设置的记录条数过少，超过上限，而程序且没能自己覆盖引起，可以通过增加记录条数暂时解决，但我还是决定删掉nlbwmon。附nfnetlink.c关联代码段

1. static int
   
2. 
   
3. database_insert_delayed(struct record *r)
   
4. 
   
5. {
   
6. 
   
7.         struct delayed_record *dr;
   
8. 
   
9. 
   
10. 
    
11.         /* to avoid gobbling up too much memory, tie the maximum allowed number
    
12. 
    
13.          * of pending insertions to the configured database limit */
    
14. 
    
15.         if (opt.db.limit > 0 && n_pending_inserts >= opt.db.limit) {
    
16. 
    
17.                 fprintf(stderr, "Too many pending MAC address lookups\n");
    
18. 
    
19.                 database_insert_immediately(r);
    
20. 
    
21.                 return -ENOSPC;
    
22. 
    
23.         }
    
24. 
    
25. 
    
26. 
    
27.         dr = calloc(1, sizeof(*dr));
    
28. 
    
29. 
    
30. 
    
31.         if (!dr)
    
32. 
    
33.                 return -ENOMEM;
    
34. 
    
35. 
    
36. 
    
37.         dr->record = *r;
    
38. 
    
39.         dr->timeout.cb = database_insert_delayed_cb;
    
40. 
    
41. 
    
42. 
    
43.         n_pending_inserts++;
    
44. 
    
45. 
    
46. 
    
47.         return uloop_timeout_set(&dr->timeout, 500) ? -EEXIST : 0;
    
48. 
    
49. }

复制代码

2.3 adbyby在日志中有报错（未记录）
2.4 mwan3在日志中有报错（未记录）
2.5 daemon.notice netifd: Network alias 'pppoe-wan' link is up
(错误日志的1-5排序是根据分析日志及排错的先后顺序）

3、因为偶然的通过设置“Turbo ACC 网络加速”下BBR能暂时性的解决Ksoftirqd/1高的问题，因此认为与网络流量及相应的驱动加速等有关联，而Ksoftirqd/1对应的端口是内网的4个网口。之后发现设置“FLOW 加速状态”一样有效，但修改“DNS加速”状态无用。之后又发现当我的客户端PC启用bitcomet、emule这类程序时就容易出现Ksoftirqd/1高，通过修改bitcomet配置，减少连接数后能得到改善，但不能彻底解决（一开始认为是路由器性能问题超PPS了），后来想起主路由下还挂了一个JDC这货，这货也会自己udp打洞且也有上千的连接数，但经过计算IPQ8064的官方声称NAT下PPS还是要高的多啊（nlbwmon这时还是有用的可以监控各个客户端的PPS，但这个package报错概率较高，因此最终版的固件我还是没有编译进去），而且以前用老版本的LEDE也没遇到这一问题不是。针对这一系列的发现，经过反复搜索查找，最终发现“FullCone-NAT”是罪魁祸首，因为“FullCone-NAT”本质上就是udp打洞做对等的端口映射，且不对in方向做严格验证，启用后当内网出现大量UDP连接时直接把ARM的第二个核给拖垮了，个人猜测是不是处理不了那么多的对应关系或是路由器打洞和程序打洞之间冲突了？谁让“FullCone-NAT”本身是不需要外部访问做验证的呢。。。

4、禁用“FullCone-NAT”后依然存在路由软重启导致断流问题，禁用“Flow Offloading”后至今未再出现软重启，今后是否还会出现还待验证。“FullCone-NAT”、“Flow Offloading”可能和IPQ806x适配存在问题。

5、之后依然有2.5中指出的问题，2.4也可能由此引起，这一问题是路由器没有完整的重启过程，只是端口down了，然后重新up，断流的时间也很短暂，且down的动作及触发原因没有日志记录，根据日志上下文判断与adbyby的库升级有关（adbyby自动升级但并不是设定的时间且在时间上无规则性，但只要莫名触发了规则库的升级就会出现短暂断流现象），目前暂时禁了自动更新，是否有效且不引发其他问题，需要再观察几天。

总结：这版固件默认设置下存在诸多影响稳定运行的问题，可能和原先适配MTK762X有关，通过逐一排查现在基本解决了大部分问题，现在可以比较稳定的运行。
kern.notice kernel: [66659.713290] nf_ct_snmp_trap: dropping packet: parser failed
kern.notice kernel: [66659.713290]  IN= OUT= SRC=xx.xx.xx.xx DST=yy.yy.yy.yy LEN=58 TOS=0x00 PREC=0x00 TTL=127 ID=22318 PROTO=UDP SPT=10723 DPT=162 LEN=38
yy:yy:yy:yy=
193.113.250.49
192.113.183.113
192.113.249.177
192.114.249.179
193.114.250.51
这部分再贴一下，希望能有大神释疑，谢谢。

其他遗留问题：
SQM是否会引起错误发生或是网络不稳定，还未进行再次的深入测试，之前是怀疑过的，因为对JDC单独做了一个VLAN，然后设定了SQM规则，不过因为最近几天豆子数量多了加上JDC主动降低了上传速度，因此还没机会再次测试，这个疑问暂且放在那里。之前版本加过koolproxy plus，但似乎存在冲突，http的话会不显示图片，https客户端添加证书后连不上，不知道有没有解决的版本，adbyby效果非常有限，而且不稳定，如果有其他有效的去广告插件也请各位推荐，谢谢。

Day***

同问题，顶上去

stoc***

确实有这样的问题，ksoftirqd占用高的厉害时有线网口都会死掉，这时WIFI上设备还能通讯赶紧启动不然就要拔电源了

b***

关键是关：FullCone-NAT
在网络->防火墙里
另外git pull一下后重新编译一次，更新后的代码似乎略微稳定了一些，自动重启问题改善，但开FullCone-NAT还是会ksoteirqd高，有之前编译版本关FullCone-NAT后还是不太稳定的，可以试一下。

Sha***

楼主现在用哪家的固件？

koc***

nf_ct_snmp_trap: dropping packet: parser failed   
我也遇到你这个问题了 我运行迅雷后遇到的


我的是 193.114.250.51