问题概述

问题来源和背景说明

客户问题现象描述及问题单

问题1：

        xx设备技术支持反馈，用户存在WiFi配网不能成功的问题，但是其他WiFi设备或者其他型号的IPC可以成功配网，并且收集了用户的路由器信息（H3C GR5200）。技术支持怀疑是xx摄像头存在兼容性问题。

问题2：

        在天津的用户现场也存在WiFi配网问题，相同情况下x型号的IPC可以正常配网，使用有线方式可以正常添加网络。

问题定位和解决

问题初步分析排查

       xx设备已经发布6个月以上，同时是出货量最大的系列产品之一，一直没有出现WiFi配网或者WiFi相关的问题反馈。上述用户的问题应该是个例情况，但是为了验证问题1，担心路由器兼容性问题，特地联系芯片厂家和系统测试咨询相关兼容性问题。系统测试反馈没有H3C系列的兼容性测试，所以还是可能存在H3C GR5200路由器不能兼容的可能性。同时，fulhan（WiFi驱动提供商）增加了H3C路由器的兼容性问题，测试发现不存在不能入网的问题，但是怀疑H3C GR5200（企业级路由器，非普通家用）路由器设置或者企业级加密方式导致。目前，公司的普通IPC都是不支持企业级加密方式，所以只可能是路由器设置或者其他原因导致。

        另外对于兼容性问题，realtek网卡之前出现过不能加入短帧方式的路由器，出现部分路由器不能加入的兼容性问题。XP1刚好也是realtek网卡，短帧问题的确认，结果发现也不存在短帧缺陷。所以对于问题1只能等待用户的路由器截图，确认是否是配置方式导致的问题。到此问题1是否没有很好的问题解决的突破口，更加没有办法去复现问题。

        在问题1的解决过程中，问题2的用户进行了反馈，在天津现场安装过程中，不能进入WiFi配网。项目现场是一家酒店，一个主路由（ssid，key），每个房间和走廊都分布有子路由器，子路由器采用AP桥接的方式和主路由连接。在酒店中，每个角落对应的都是相同的ssid和key，但是实际上对应不同的路由器。在任意一间房中，可能接收到多个相同ssid和key的热点，因为本房间和隔壁房间都是相同的。

客户问题分析

        本款产品采用是Fullhan的RThread的RTOS操作系统， WiFi驱动是从Linux上移植而来，在rtl8188的WiFi芯片上是首次使用，所以很有可能存在潜在的bug。

        在问题2中有个特殊的场景，即AP桥接情况下（或者多个相同SSID和key），设备是否可以正常入网。采用2个相同的ssid和key的路由器，进行验证测试，发现确实存在入网问题。

        同时，再次联系问题1客户确认是否也存在AP桥接或者多个相同SSID的路由器。技术支持反馈用户就是采用AP桥接方式，到此问题1和2的基本可以定位了。

        对于问题1和2的情况，反馈给fulhan支持，确认是ap桥接情况下存在问题，由于在linux环境下配网由Wpa支持，但是RTOS上没有移植Wpa相关内容，且没有全面考虑ap桥接导致。

进一步分析

        在AP桥接情况下（或者相同SSID和密码），WiFi不能正常入网的原理是什么。在AP桥接方式下，一般主路由器和从路由器采用相同的SSID和密码（虽然从路由器可以设置不同SSID和密码），这样对于用户来说只要输入一次SSID和密码即可在所有路由器范围内正常使用。所以AP桥接入网方式，本质上就是多台相同SSID和密码的设备，每个AP的唯一区别是MAC地址。为了WiFi热点的覆盖性，一般情况下，每个位置都存在多个相同SSID的热点可以加入。

        从源代码分析看，在入网过程中获取路由器相关信息，只对SSID和其长度进行对比，所以在SSID相同的情况下，IPC就不能区别上次接收的SSID信息来自子路由器1还是子路由器2，导致在入网过程不能完成4次握手，实现WiFi配网完成。   

        在IPC在入网scan过程中，接收到多个SSID相同的路由器时，RTOS版本的驱动没有记录每个SSID对应的MAC地址（或BSSID），所以导致在入网过程中，4次握手发送出现“张冠李戴”情况，自然难以完成配网成功的情况。

产生原因

        通过上诉的一系列排查，明显发现rtl8188驱动在移植到RTOS上存在明显的漏洞，对于AP桥接或者多个相同SSID情况下，没有充分测试和支持。Fulhan也表示在实际移植过程中，没有充分考虑到AP桥接的场景，从而导致了漏洞的出现。

        另外在IPC的驱动开发和测试过程中，也缺少类似的测试用例，在开发阶段没有及时发现存在风险。

问题故障后续处理

        在WiFi驱动定位清楚后，要求fulhan主导修复WiFi的驱动，我司负责WiFi驱动测试和验收。WiFi驱动修复方式，增加SSID的判断，记录信号最强的SSID的MAC地址（或BSSID），后续入网交互和指定的路由器进行，这样避免了4次握手混乱的情况。

        验证测试，搭建2个相同的SSID的路由器，设备进行配网操作，进行多轮次测试验证，没有一次失败。WiFi驱动验证测试通过，发布WiFi驱动更新到SVN，通知应用开发打包发送临时程序到客户现场验证。客户升级最新的IPC固件后，再次进行配网操作，可以正常WiFi配网，问题解决。

        内部风险评估，RTOS版本的驱动目前只有一款产品，后续直接升级程序即可完成修复，不涉及其他产品。另外，通知系统测试相关人员，反馈相关问题，评估是否后期增加相关测试用例。

问题最终结果和总结

        客户使用最新版本的设备固件后，解决现场不能采用WiFi配网的问题。客户问题研发子单关闭处理。

       WiFi驱动新平台的测试用例需要增加AP桥接等使用场景，尤其是RTOS版本驱动，一般都有fulhan移植，可能存在较多的缺陷。