究竟是测试重要，还是工程重要？

近期一直在负责IPV6一致性测试的工作，也负责解决一些问题，但今天碰到一件匪夷所思的事情，让人不可理解。

事情是这样的，在工程代码中，也就是现网要运行的版本，前人做了一个极其错误的修改，可以用错的离谱来形容，也就是收到NS报文后的处理，RFC4861这样描述到：

If the Target Address is tentative, the Neighbor Solicitation should be processed as described in [ADDRCONF].  Otherwise, the following description applies.  If the Source Address is not the unspecified address and, on link layers that have addresses, the solicitation includes a Source Link-Layer Address option, then the recipient SHOULD create or update the Neighbor Cache entry for the IP Source Address of the solicitation.  If an entry does not already exist, the node SHOULD create a new one and set its reachability state to STALE as specified in Section 7.3.3.  If an entry already exists, and the cached link-layer address differs from the one in the received Source Link-Layer option, the cached address should be replaced by the received address, and the entry's reachability state MUST be set to STALE.

重点看最后一句,也就是当NS报文时，neighbors要设置成STALE状态，代码片段应该是这样的：

               bool nd_update;
    
                nd_update = memcmp(opt->nd_opt_data,
                                         peer_neigh->lladdr,
                                         netif->ipcom.link_addr_size) != 0;
    
                if (nd_update
                    || (peer_neigh->state != ND_REACHABLE
                        && peer_neigh->state != ND_PROBE
                        && peer_neigh->state != ND_DELAY))
                {
                    neigh_set_lladdr(peer_neigh, opt->nd_opt_data);
                    neigh_set_state(peer_neigh, ND_STALE);
                }

结果有位同事将代码改成了neigh_set_state(peer_neigh,ND_REACHABLE); 看到这行代码感觉不对劲，明显的没有遵循RFC。于是找到修改的同事，问他是基于什么原因要修改成这样？他告诉我说，是上面强行安排的，他当时也及其不情愿修改，说是为了应付测试仪的问题。

听到这里，觉得这也太搞笑了，究竟是测试仪的测试重要，还是工程版本重要。这样修改放到现网中运行，如果攻击者伪造一个NS报文，同时option选项中附带一个不存在的MAC地址，产品一处理，与此相关的业务全部断掉，这个责任谁能承担的起？孰轻孰重，放在手里掂量一下，就不会做出一个极其错误的决定。个人认为，这种错误是不可饶恕的。

在开发过程中，不论是做出决定，还是修改代码，不要想当然。没有经过深思熟虑的修改代码，就是后续不停的改bug。一个没有经过深思熟虑做出的决定，就是后续不停擦屁股，返工！

让我们对做事保持一个敬畏心！做事不要太想当然！