今天又是解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:

1. CPE1 and CPE2 connect to SVD LAB
2. CPE1 and CPE2 set to IPoE mode and disable NAT function
3. Set CPE1 LAN IP to 192.168.1.x and enable RIPv1 with Active mode
4. Set CPE2 LAN IP to 192.168.2.x and enable RIPv1 with Active mode
5. Check routing table of CPE1 and CPE2 via GUI and CLI route
6. Check CPE WAN site RIP packets
7. From CPE1 LAN-PC to ping CPE2 LAN-PC
8. 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. 解决问题的思路：首要目标还是快速确定问题是否是已知问题。老代码已有的，而不是新引入的就可以放低优先级，和项目经理多沟通沟通甚至可以不搞也说不定呢。先搞其他更加重要的问题。这样省下来的时间就可以用来学习新东西。