RS预览失败问题分析和解决

摘要：某自研扫地机器人(RS2)在使用WiFi6路由器时出现预览失败问题。经排查发现，WiFi6路由器与RS2的rtl8192fs网卡存在兼容性问题，导致服务器推送的TCP数据包最后4字节被概率性截断。通过原厂提供的补丁修复FCS机制缺陷后，问题得到解决。验证测试表明，使用tcpdump抓包是复现该问题的有效方法，而TCP客户端接收数据方式难以复现。该案例为类似WiFi6兼容性问题提供了排查思路，

dozenyaoyida

240人浏览 · 2026-02-12 10:24:30

dozenyaoyida · 2026-02-12 10:24:30 发布

背景介绍

xx自研第二代扫地机（型号RS2，下文使用RS2表示）在体验用户家中，出现更换xx自研的路由器后出现预览出图困难的问题。用户出现该问题后，第一反应是自研路由器存在问题，因为RS2已经经过多轮验证并且通过路由器兼容性测试。因此该问题反馈到路由器开发组，要求排查原因并解决。

但是路由器相关人员对设备进行验证，使用H3C相同方案的路由器（WiFi6），老版本的W3c路由器分别进行验证测试。

路由器开发人员对扫地机测试验证发现，使用H3C相同芯片方案的WiFi6路由器存在相同的问题，概率性出现不能正常进入预览的问题。但是如果使用老版本W3C路由器（非WiFi6）可以正常预览，且预览进入速度也较快。因此怀疑RS2的网卡rtl8192fs对WiFi6路由器存在兼容性问题，要求排查和解决。

问题排查和分析

RS2在自研WiFi路由器上预览失败，第一反应是不是干扰较大，吞吐量不够导致预览失败，这是一个很常见的问题。

因此下面的测试验证。

自研WiFi6路由器切换到13信道，相对干扰的环境下进行验证测试，发现问题并没有改善；但是不是必现情况，10次中可以出现几次失败。预览使用手机连接外网进行，预览通过服务器取流。
RS2上安装Iperf打流工具，对自研WiFi6路由器进行Iperf打流测试，是否存在吞吐量不够的情况。测试发现吞吐量在20-30M，对于预览来说余量非常大，不应该存在卡顿问题。
对于普通路由器在相同的条件下（相同位置，相同信道），进行验证测试，RS2预览比较顺利，并没有出现失败的情况。
局域网预览测试验证，发现局域网预览不存在失败问题。但是手机预览比较容易出现预览失败。RS2局域网预览，由WiFi连接到路由器，再由路由器连接终端，不经过云服务器。这个预览结果符合我们打流的预期。

通过上诉的验证，我们可以看到RS2和WiFi6路由器的连接实际上没有问题，从打流数据看，但是为什么只要通过云服务器进行取流就存在异常？？

对于上述的验证和怀疑反馈给相关人员，要求给出相关说明，预览相关人员告知，使用服务器预览取流数据不同，服务器会推送一包取流的数据，但是局域网取流不存在该数据帧。此时，我们有理由怀疑，是否该取流数据帧异常了，导致不能正常的进行取流，导致预览失败，而并非是WiFi吞吐量问题。所以，我们要求RS2开发人员对本地进行抓包，分析取流数据是否存在异常，导致取流失败，下面是RS2本地的抓包数据（tcpdump抓取wlan0口）。

上图中60.190.232.76是服务器IP地址，192.168.1.78是设备IP地址，可以看到服务器前面4次发送TCP报文的长度是728字节，但是最后一次的长度是732字节。通过对数据的分析，可以明显发现728字节的数据比732字节的数据少4字节，且是最后4个字节。

从上诉分析看，RS2确实可能存在对WiFi6路由器存在兼容性问题，由于对取流数据报文的概率性截断（丢失最后4字节），导致RS2不能正常取流。所以对于这个问题，我们进行2步操作，第一将问题反馈给原厂，是否有遇到过类似情况，第二搭建测试验证环境，复现上述问题，并且确认是否RS2接收到完成的数据帧还是WiFi6路由器发送了异常的数据报文。

对于该问题的复现环境相对比较复杂，下面将详细描述复现的过程和排查。

需要准备的工具和环境。

自研WiFi路由器，如W3X，目前在该路由器上出现问题，或者使用H3C TX1801 Plus。
可连接服务器的外网，正常公司网络不可用。可使用4G转WiFi路由器等。
WiFi无线抓包软件和工具，软件包括WireShark，Omnipeek，硬件使用NETGEAR的USB无线抓包器。
RS2正常使用的设备和程序，支持tftp，tcpdump等；
xx云视频APP。

问题复现环境搭建。

上电连接外网的路由器，使用xx云视频APP将扫地机添加到该路由器上，通过手机可以预览扫地机视频；路由器建议切换到干扰较少信道，这边测试使用13信道。
打开WiFi抓包工具，将RS2的Wlan0作为过滤条件，设置路由器SSID和秘钥。
RS2进行重启，WiFi抓包RS2入网过程（完成抓取WiFI入网的4次握手），直到可以解析到RS2的TCP协议数据帧；
WiFi网卡将RS2的服务器IP地址作为过滤条件，同时设置TCP协议。目的为了更好的查看服务器发送给RS2的TCP数据帧，可以更快的找到需要的数据。
登录RS2设备，输入tcpdump -i wlan0 -w /tmp/a.pcap，搭建tcpdump工具，同时将完整的抓包数据保存到a.pcap文件中。
手机连接4G网络，进入xx云视频对RS2进行视频预览测试。预览成功，正常进入视频，表示成功1次，退出后再次进行预览，直到出现预览失败。实际测试下来，10次预览可以出现几次的失败。

对于预览失败的情况，暂停保存WiFi抓包和tcpdump，将WiFi抓包数据和RS2的网口抓包数据使用wireshark打开，进行错误数据分析。TCP数据中函数字符串“/3100/12545”就是取流数据帧，由于该数据帧并非固定长度的数据帧，长度在700-1000字节都有可能。

无线抓包数据中，看到路由器发送给RS2的WiFi数据的取流数据的TCP数据长度666字节，但是RS2上wlan0抓包的TCP数据长度只有662字节，所以可以确认录取发送数据是正常的，RS2上丢失了4个字节数据，确认后确实是最后4字节（TCP报文）。

对于TCP报文确认方式，如果进行了多次的预览测试，可能存在多次的TCP数据交互，此时需要注意WiFi抓包和设备端抓包是否是同一包数据。建议使用TCP的序列号进行区分。

设备端TCP数据序列号4F CE BC 33，WiFi抓包的数据序列号同样是4F CE BC 33，所以可以确认是同一包TCP数据。但是我们需要注意，设备端对于同一包TCP数据可能存在不同解析，有时候第一次解析是正常的，有时候前面几次解析异常，后面的解析正常。

进一步分析

通过上诉的分析，我们可以明显看到RS2对于部分无线数据存在截断的问题（丢失最后4字节），并且该现象和部分WiFi6路由器有关，并且是概率性出现该问题。

原厂技术人员经过内部分析后，怀疑可能后FCS机制有关系，之前也有可能出现类似丢失最后4字节的问题，同样也是在WiFi6路由器上，Patch的说明如下。

进一步确认patch修复的机制，原因和影响。从原厂回复看，简单理解是部分WiFi6数据处理存在缺陷，导致将部分数据的FCS移除错误，多移除一次。所以patch修改就是避免这种情况发生，增加判断移除FCS的数据帧修改该缺陷。

解决方案

RS2合入原厂提供patch后，再次使用相同的方式进行问题验证。验证10次以上，没有出现预览错误，同时抓包分析没有出现丢失最后4字节的问题，证明问题已经解决。

修复后的驱动版本提供RS开发进行测试验证，测试超过40次，没有出现一次预览失败的问题。

另外其他类似网卡如rtl8188fu，rtl8189fs是否存在相同问题，需要如何验证该问题，是否可以很快的复现？

同时对于新导入的网卡是否需要增加类似的验证测试，但如何验证测试？这些都是问题，为了验证上诉问题，rtl8192fs和WiFi6数据丢失的长度关系，将测试方案进行改进。RS2上增加TCP客户端，PC上开启TCP服务器，PC模拟发送类似的TCP数据进行测试验证，RS2打印对应的数据和长度，同时打开tcpdump进行验证确认。但是很遗憾，目前从测试数据看，并不能很好的复现上述的问题，所以对于IPC上的类似问题需要进行另外的探索，也就是一个新的课题。大部分IPC上资源有限，没有多余空间可以安放tcpdump这样的工具，且按照RS2解决问题测试的环境搭建，整个过程比较复杂。

对于网卡丢失4字节问题，RS2上虽然已经解决，但是是否可以同步解决其他项目上的问题，目前看还需要进一步验证和测试。目前看，环境模拟的方式进行问题复现，未必可以复现问题，采用相同方式对IPC进行问题验证也同样有待验证，该问题需要持续关注。

从RS2上大量测试验证发送，TCP客户端节点的数据基本上没有异常情况，但是从tcpdump的抓包数据看存在重发情况，出现上述的丢失最后4字节的问题。因此验证该问题使用TCP客户端接收数据测试的方式可能难以复现，使用tcpdump抓包的方式才是比较合适的复现方案。

对于TCP客户端接收数据全部都是正确的，但是tcpdump可以抓取到异常的数据，进行分析。从下面的截图，我们可以发现实际TCP数据报文是742字节，但是tcpdump到data数据长度只有738字节，总长度和包长度不符合，实际上这是一个异常的TCP数据报文。所以TCP客户端没有接收到该数据报文，TCP客户端中采用recv接收TCP的有效数据，必须都是合法的TCP数据。