网络相关问题(上)

TCP/IP网络是一个复杂的话题，其中涉及到的驱动、协议栈和应用编程每个主题都够写一本书。事实上确实有许多这方面的巨著，如《TCP/IP详解》三卷本、《UNIX网络编程》等等。这里先列举几个印象比较深刻的案例，后续还会再补充。

案例1：MAC地址唯一性

MAC地址需要是一个全球独一无二的值，但对于某些未配置MAC地址的芯片，需要人为写入一个MAC地址，这时若将其连入网络中，要保证其与网络中其他设备的MAC地址不冲突。因此该MAC地址由主控芯片生成并下发，生成算法来保证各芯片不同。MAC高24位表示厂商，后24位由厂商自行分配。可以将前24位修改为一个冷门厂商的代码，后24位使用主控芯片的唯一ID。当所有主控芯片都来自一个厂商时，生成的所有MAC地址都不同，这样的一些设备组成的网络不会出现MAC冲突。
但在没有仿真调试状态下只能在代码中用宏来配置，这时每个芯片的MAC地址将一样，从而导致MAC地址冲突。此时利用仿真器可以调用fopen等函数来读上位机的某个文件，不同上位机文件内容不同从而MAC地址也不同。

案例2：MAC地址合法性

手动配置MAC地址时，曾经有一段时间网络总有问题，后来各种手段排查定位到某块板子的MAC地址有问题，原来其MAC地址的Bit40配置为1，而该位是单播/广播标识，当配置为1时为广播包，因此影响了正常网络通信。
还有一次网络出现问题，最后发现是某块板子的启动时序出现问题，MAC地址没有配置为正确值，而是未初始化的全0。这时恰巧C6455的驱动中对全0地址检查代码少了一个分号，因此将此地址错误放行。将该分号加上则可以判断出非法地址，及时发现问题。

案例3：诡异的手动点击

在C6455上移植NDK协议栈时，为了测试协议栈运行是否正常，开设了两个后台服务，分别是TCP和UDP的7号端口。两个服务都是把所有收到的数据原封不动的返回，即echo功能。在某次测试时，测试部同事们在PC机上做了一个测试软件，一个按钮点一下建立一个TCP连接，然后另一个按钮每点一下发送一包数据，还可以自动发送数据。
但在测试时发现，手动点击时经常有时候发送的数据C6455不响应，需要重启软件才行，而自动测试却从未出错，一直未找到原因。后来花费几个小时来点击，终于总结出规律：两次点击之间间隔太长则下一次数据就不会响应。顺着这个思路再查资料，最后找到原因是作为服务器端，为了节约资源，TCP连接的保活时间被设为5秒，当5秒内无数据时该连接被断开，后续再发送的数据当然不会再响应。
事实上连接断开时TCP双方会有四次握手，作为客户端一方是需要有能力检测连接是否已断开的，但测试软件编写不完善导致了这个诡异的问题。最后修改测试软件加入一个断开连接的提示。

还有一些之前总结的文章也直接或间接和网络相关，如《C6414上移植LwIP》、《实时操作系统若干问题》中的案例2和3、《C6678网口初始化失败》、《C6455上移植SYS/BIOS》中案例2、《NDK持续打印》等等，也可以看出网络相关问题曾经造成多少麻烦。

网络调试时最重要的是确定网络环境和网络配置，否则MAC地址冲突、IP地址冲突这些问题会导致许多诡异现象无从下手。最好的解决方法是先确定网络拓扑，再减少无关设备，最好是采取直联方法缩小网络规模以快速定位问题。
另外Wireshark在网络调试中必不可少。灵活使用其强大的抓包和分析功能可以达到事半功倍的效果。