今天又是解bug的一天，手上有5~6个bug，目标每个工作日解决一个。(红色的字是晚上整理复盘的时候加的。黑色的是边干活边记录的，怕思路太混乱丢三落四的做完就忘)
第一个bug：PC隔着路由器，PING不通。看着比较简单。实际上最后花了一整个工作日。
下面是PQA的bug描述↓
Bug #13925
[b1][NAT/Routing/DDNS]config CPE1 and CPE2 RIP mode, CPE1 LAN-PC can’t ping CPE2 LAN-PC
描述
Steps:
- CPE1 and CPE2 connect to SVD LAB
- CPE1 and CPE2 set to IPoE mode and disable NAT function
- Set CPE1 LAN IP to 192.168.1.x and enable RIPv1 with Active mode
- Set CPE2 LAN IP to 192.168.2.x and enable RIPv1 with Active mode
- Check routing table of CPE1 and CPE2 via GUI and CLI
route - Check CPE WAN site RIP packets
- From CPE1 LAN-PC to ping CPE2 LAN-PC
- From CPE2 LAN-PC to ping CPE1 LAN-PC
Expectation:
CPE1 LAN-PC ping CPE2 LAN-PC should work well in step7
Problem:
CPE1 LAN-PC can’t ping CPE2 LAN-PC in step7
Other:
CPE1 and CPE2 disable firewall fuction, CPE1 LAN PC ping CPE2 LAN PC work well
这个很明显了吧：目测是FIREWALL规则的问题。
先看BackEnd配置firewall的时候搞了些什么操作↓
beFirewallConfigLoad
beFirewallV4Execute
beFirewallConfig(IPVER_4);
/*==Device.Firewall.Config==*/
void beFirewallConfig(int domain){
iptCfg_t *ipt = NULL;
zyUtilInitIptablesConfig(&ipt);
inserGeneralRule(ipt, domain);
/*config*/
insertConfigRule(ipt, domain);
insertServiceRule(ipt, domain);
//beExecuteScriptFile(fp, scriptFileName, true);
zyUtilRestoreIptCfg(ipt);
}
看到这里已经花了不少时间，觉得死看代码好像不太容易看出来，毕竟越往后看分支也越多，容易陷入细节。具体代码中加入的规则，还可能和实际板子上iptables -L出来的不太一样。（复盘：那是我还没习惯iptables命令。看规则详细的过滤条件，后面应该跟 -nvL才能看到）
所以，还是决定动手实践一下！嘿喂狗~
实验1： wan配成一条bridge wan，直接从wan口接上个PC, ping lan侧PC。
firewall开关默认都开启状态。
先iptables -nvL保存一下目前的规则表。
默认的br0 addr：192.168.123.1
lan侧PC配置了一个192.168.123.222
wan侧PC配置一个192.168.123.111
然后，见证奇迹的时刻： wan ping lan => 居然是可以ping通的。 lan ping wan =>也可以ping通。
测试方法理解的不对？(复盘：确实不对，后面可以看到这种情况下不会导致丢包。因为导致丢包的条件对bridge口正好无效呢。而bridge wan的wan口实际上也认为是一个bridge口，和eth口地位基本是平等的)
还是照抄PQA的配置来试试。。。。吗？（当时想，还没到认输的时候呢，还可以抢救一下）
先试下wan配成routing wan， static ipv4。。。 wan侧pc和wan口配置成gateway互指。
好了，老运维的手速瞬间配完。再次见证奇迹的时刻： wan侧pc ping wan口，先试试。。==>没ping通耶。。感觉有戏哦
wan侧pc ping lan侧pc ==>大概率ping不通吧？毕竟到wan口就没回应了。==>确实。没响应。一样的效果。no respond found. (这里有个小问题：为什么再echo request消息里就带了这个No response seen字段。大致看了一下，并没有对应的字节。应该是wireshark根据后面没有收到应答消息，软件自己添加的说明)
好了，下一步，关了firewall试一下。
2021-7-30 14:39:42 下午时间还是够的。争取下班前解决这个问题。先去喝点东西。(做什么做啊，饮茶先啦-_-)
关了ipv4的firewall，其他配置一概保留(这你妹滴 喝完茶居然都15：20了？？)
直接贴截图：↑
现象比较奇怪，一开始ping wan口地址，都没ping通。我都觉得没戏了。但居然绝处逢生，ping lan口pc，通了！针不戳，嘻嘻。
下一步，先保存一下iptables -nvL的记录，比较一下条目的区别呢。
比较之后，开不开ipv4 firewall的区别主要在LevelLow这个chain有条目的差别。
直接在BackEnd的代码工程下暴力搜索LevelLow
static void insertConfigLow(iptCfg_t *ipt, int domain){
char lanName[6] = "br+";
char chainName[MAX_CHAIN_LEN] = "LevelLow";
应该就是这个函数：（实际上整个工程里也只有搜到这一处，有点信心好不好？LevelLow应该是默认的防火墙低安全级情况下应该支持的一个过滤链吧。这™滴还需要有多处定义吗？）
实际加上了规则的是这两句：
fprintf(fp_f, "-A %s -i %s -j ACCEPT\n", chainName, lanName);
fprintf(fp_f, "-A %s ! -i %s -j DROP\n", chainName, lanName); //in != br+ ，DROP 。wan口的Name为nas0_0，不幸中枪
小问题：RDM_OID_ROUTING_ROUTER 这个表是干嘛的，有空调查下?（还是不太清楚，下周问问小boss们）
Chain FORWARD => Chain FORWARD_POLICY =>Chain LevelLow
这里把 in != br+ 的包都DROP了。也就把wan口来的PING包丢掉了
老大这时候打水路过，来关心了一下，让我看下DX3301（很多已有功能代码是直接从这个产品上继承来的）是否有相同的症状：如果有一样的问题，就把优先级先放低。
花几分钟动手测了一下，果然效果是一样的。所以就优先级放低咯？还是先发消息请示一下主持这个项目的小boss 大明同学，结果人家太忙了，懒得理我。好吧，反正到点了，喝口水润润喉咙，下班过快乐的周末去了，完成工作的这个周末可以说是毫无压力了吧？下周继续相同的节奏，大搞特搞吧！
经验总结：
1. 花了比较多时间的主要原因：基本的iptables基础不太扎实。知道很可能是它的某条规则导致了丢包。但一开始-L打印出来的并没有显示rule的过滤条件。因为以前也没太多这个经验所以心里没底，很担心一开始就走错方向啦。后面运气好发现-nvL可以显示过滤条件（当时是想显示每条规则通过的包或拦截的包的数量，方便定位问题，这才发现这个命令原来显示的信息挺多）
2. 解决问题的思路：首要目标还是快速确定问题是否是已知问题。老代码已有的，而不是新引入的就可以放低优先级，和项目经理多沟通沟通甚至可以不搞也说不定呢。先搞其他更加重要的问题。这样省下来的时间就可以用来学习新东西。