解决向NAS上传文件偶发损坏故障

Trouble Shooting

故障诊断与处理责任编辑：赵志远解决向NAS上传文件偶发损坏故障■ 辽宁 彭硕 赵志永某单位有一台编者按： 通过WiFi向某品牌NAS（Network Attached

可发现配置并无Q品牌小型NAS（以Storage，网络附属存储）上传文件，偶发文件损坏明显不当。依下简称“该NAS”），（HASH改变）故障。笔者通过深入分析，分别确定了位照NAS厂商技术通过双网口链路于NAS、AC和AP上的故障原因，并给出了缓解故障的人员指导，对配聚合（LACP）直连方法。置进行了优化调核心交换机。该整，故障未能缓NAS为单位部分员工提供一段时间以来，管理员经解。SMB文件共享服务。常接到用户反馈：通过WiFi随后管理员对该NAS进该单位网络结构为：核心向该NAS上传的文件有概率行了如下排障尝试：升（降）交换机万兆光纤到楼层，三发生损坏（即已上传至该NAS级软件版本，恢复出厂设置，层交换机千兆网线到桌面；中的文件HASH发生改变），更换全部硬盘，改变网络（聚H品牌无线控制器（AC）直连但使用有线网络则没有问合）设置，更改网络接入位核心交换机，各办公室及公题。置，更换网络跳线等，但均未共区域部署有H品牌瘦AP有任何改善。因该NAS的内（11AC），AP全部工作在集中初步分析与排查存固化在主板上，故未能对转发模式。通过检查该NAS的配置，内存进行替换测试（纯有线【上接第155页】过来的，而一个三角形的环路，如图3没有明显故障痕迹，但网络不是通过默认网关SW3-1。所示。性能就是不正常。如果没有分析完这几个包，真相大如果这是一道网络工程一定的内功，就束手无策了。白。我们可以看到通信过程师入职面试题，相信会有很实验小结：部分学生反映是这样的：PC0先把Ping请多故事发生，它不单单考查在模拟器上做实验可能不通求交给默认网关SW3-1，默认应聘者对基础知识的掌握程（可能是版本的问题），但是在网关再转发给PC1，而PC1收度，更是检验工程师对协议真实环境下，分别用华三、锐到请求后会直接把Ping通原理的深入分析了。一旦在捷、神州数码和思科设备搭建，过SW2-1回复发给PC0，形成真实环境出现类似现象，又都能正常通信了。1562021.05

投稿信箱：**********************

责任编辑：赵志远

故障诊断与处理Trouble Shooting网络或内部传输测试均正或HTTP协议均受如在测试中选用任意文常，因此几乎可以排除内存影响。HTTPS协议虽不会导件，其二进制编码就没有规故障）。致文件损坏，但其速度极慢。律可言（指人眼可以分辨的管理员通过使用不同终如仅依前述第3～5点，十六进制数据排列规律），人端、网卡、服务器和网络设可推断故障位于无线网络设工目视检查时难以快速辨备，进行了若干组交叉对比备。但仅依前述第9点和第别。通过制作一个特殊的测试，方查明故障。部分规10点，则可推断故障位于该二进制测试样本文件，即可律如下：NAS。这两个观点看似相互有效降低数据对比的工作协商速率在300

矛盾，但却无法有力地排除难度。但考虑到前文中推定Mbps以上更易复现故障。第三种可能：即故障同时存的文件损坏原因，以及IP分2.无线传输实际吞吐量在于该NAS和无线网络设备组中载荷的最小可分辨单在10 MB/s以上更易复现故中。位（字节，指IP报文首部的障。至此，故障已经无法继续“Total Length”字段），应避3.故障可在多种型号的通过“替换法”进行简易排免使用单一字节（如0x00）H品牌无线设备上复现（均为除。另外，从第10点可以推对文件进行填充，否则即便V7软件版本），但无法在R品测，HTTPS速度慢是由于完发生数据错位，也无法分辨。牌无线设备上复现（均为AC+整性检查未通过导致重传造综合以上考虑，使用8 B瘦AP+集中转发）。成的。这意味着分组（数据长度的数据“0x000102030

4.多个品牌和型号的无包）在传输过程中极可能发4050607”对测试样本文件进线网卡均受影响（均为11AC

生了损坏，因此必须使用网行填充是较为合适的。在先/11AX无线网卡）。络分析技术（抓包）进行分析前的测试中，已查明200 MB5.仅使用有线网络（任意测试。以上的文件可以有效复现故速率）无法复现故障。障，故将此测试样本文件的6.上传尺寸较大的文件NAS故障的确认与解决体积设定为300 MB。MB以上）更易复现故障。经反复测试发现，该NAS具体操作方法为：在Win

7.故障与该NAS的配置上存在的已损坏文件，其大Hex软件中选择“新建”，并及其网络接入位置无关。小（体积）与终端电脑上未设定文件体积。点击“搜索”8.故障与终端电脑的操损坏的文件完全相同，据此菜单下的“替换十六进制作系统版本或SMB协议版本可以合理地推测文件损坏原数值”，在“搜索”框中填入无关。因应为“数据重组顺序错误”“0000”，在“替9.故障仅能在该NAS上（指文件二进制数据的顺序换”框中填入“

复现，使用S品牌NAS或Win

不正确，并非指分组的“乱序0607”，选中“替换所有”单dows主机共享则无法复现。到达”）。选框，并点击“确定”。结果投稿信箱：********************** 2021.05157（200

Trouble Shooting

故障诊断与处理责任编辑：赵志远如图1所示。测试样本文件制备完毕，即可进行下一步工作——抓包分析。数据包捕获位置，可设置在该NAS与AC之间。此举便于观察AC是否向NAS传送了正确的分组（数据）。抓包所使用的设备为“硬件端口镜像交换机”（非网管型），此举可尽量避免对网络交换设备的运行环境（配图1 测试样本文件中的数据置）造成影响（更重要的是克服了“修改交换机配置是否会影响故障复现”的心理障碍）。抓包所使用的软件为“科来网络分析系统2020技术交流版”与“Wireshark 3.4.

3”（均为免费软件）。前者可对多种网络故障生成告警图2 分组中携带的错误载荷数据事件集，便于观察；后者则对流、分片的重组具有良好支持。二者生成的抓包文件格电脑（Windows系统）上使用行抓包。式可以互相兼容。“net use * /del”命令删除上传完毕后，对比该NAS为简化TCP协议的工作先前已经建立去往该NAS的连与终端上测试样本文件的行为（也就是简化分析过接。因为TCP的窗口缩放因子HASH，发现上传到该NAS的程），事先已在该NAS上关闭（Window Scaling）仅在TCP握文件已经损坏。将损坏的测了TCP SACK功能（TCP Se

手时交换一次，若未能捕捉到试样本文件复制回本地，使lective ACK，Linux命令“sy

握手报文，则后续TCP报文的用WinHex软件的“比较”功sctl -w _sack

“窗口大小”无法正确识别。能与原始文件进行对比，观0”）。使用终端电脑向该NAS察到两个文件共存在7处差注意：抓包前务必在终端上传测试样本文件，同时进异，每处均为连续206 B，累1582021.05

投稿信箱：**********************

责任编辑：赵志远

故障诊断与处理Trouble Shooting积差异1 442 B。表1 被放行的错误分组与受损样本文件的对应关系导致这些差异的可能原因有二：一是该NAS通过网络收到了正确的数据，但在处理数据并写入磁盘的过程中出错；二是该NAS从网络收到了错误的数据，并将错误数据写入磁盘。至于真相为何，还需分析捕获的网络数据包。“科来网络分析系统”的校验和错误的分组中，有16（checksum offload）。因此，选项卡中，存在23个个发生了重传（且重传分组网卡（或驱动程序）故障导致非法的校验和”提示。的TCP校验和正确），7个没忽视错误TCP校验和的可能与之对应的23个分组长度有发生重传。这7个没有发性极大。均为1 514 B（不含FCS），且生重传的分组，其数据的错Linux系统提供了eth

均是由终端发送至该NAS。误模式和先后顺序，均能与tool命令，用于显示或修改观察这些分组载荷的十六进前述受损样本文件中的7处网卡的属性。使用该命令依制数据，发现全部23个分组差异一一对应。如表1所示。次尝试禁用该NAS网卡上RX最后的206个 B均为“错位”该实验结果证明：该NAS（入站）方向的多个offload状态（从偏移量0x51c开始）。有概率无视TCP校验和错误，功能，最终发现在禁用GRO如图2所示。将不正确的数据写入硬盘。（Generic Receive Offload）根据TCP协议的工作原使用另一S品牌NAS和后，该NAS在任何情况下接理，接收方必须验证TCP校Windows主机共享进行实验，收的文件均不再损坏。验和，未能通过验证的分组发现这二者不会忽视TCP校该NAS有两个物理网口，应当被丢弃。因被丢弃的分验和错误，所有错误的分组因此需要在两个网口上同时组无法产生确认（ACK），发均被丢弃（并等待重传），因禁用GRO功能，否则在双网送方必然会对该分组进行重此在这二者上无法复现文件口组成聚合（bond）时依旧会传。通过检查网络中是否有损坏的现象。出现问题（无需禁用bond接重传（拥有相同特定序列号Q品牌NAS使用基于口上的GRO）。命令如下：的TCP报文）发生，即可判断Linux的系统。在通常的实ethtool -K eth0 gro

该NAS是否真的丢弃了这些现中，为节约CPU资源，报off错误分组。文头部校验和的计算（检查）ethtool -K eth2 gro

检查结果表明，23个TCP工作多交由网卡进行处理off投稿信箱：********************** 2021.05159“诊断”“TCP

Trouble Shooting

故障诊断与处理责任编辑：赵志远使用ethtool命令修改的设置无法永久保存，故上述命令仅能在重新启动前保持生效。该NAS系统经过深度定制，必须使用厂商提供的特定接口，方能在系统启动时执行脚本命令。参考该NAS厂商的说明，将上述命令图3 孤立的CAPWAP分片报文写入文件中，并反复重启NAS，确认设置持进行封装。但终端的无线片中进行搜索（Wireshark续有效。反复上传文件至该网卡MTU为1 500 B，另附上过滤器表达式为“_NAS，同时抓包，发现仍存在UDP和CAPWAP数据报头等结raw == 序列号”），观察到TCP校验和错误的分组，但该构，终端发送大量数据时的如下结果：所有TCP校验NAS上的文件不会再损坏，至IP报文长度已超过以太网和错误的分组，在其对应的此故障得以解决。MTU默认值（1500 B）。此时，CAPWAP封装中均拥有一致的AP会对CAPWAP数据报文进分片ID——本案例中均为AC/AP故障的确认与解决行分片处理。12 252。前一个章节中的实验结CAPWAP数据报文头部CAPWAP数据报文头部中果证明“：数据错位”（且TCP中，分片ID（Fragment ID）的分片ID字段，其长度为校验和错误）的分组是由AC字段、分片标志（Fragment

16 bit，所表示的十进制范围发送给该NAS的。这表明AC

Flag）和最终分片标志（Last

仅为0～65 535。在大尺寸/AP上同样存在故障。Fragment Flag），共同指出文件传输的过程中（可能需保留前述在NAS与AC之哪两个分片是从同一个以要发送数十万或上百万个分间的抓包点（简称“抓包点太网帧分离的（在MTU为组），分片ID在时间线上呈1”），并在AC与AP之间新增1 500 B的以太网中，CAPWAP现反复重复，是其空间范围第二个抓包点（简称“抓包点数据帧通常被分为两个分过小的必然结果，并非故障。2”），同时确保终端始终关联片）。AC收到这些CAPWAP分在抓包点2捕获的CAP

到这台被测AP。重复上传文片后，会尝试将其重组为一WAP分片中，使用特定的分件到该NAS的过程，在两个个以太网帧。片ID进行搜索（Wireshark抓包点同时进行抓包。在抓包点1捕获到若干过滤器表达式为“capwap.因无线网络设备采用集TCP校验和错误分组，将其 == 12

中转发模式，AP发送给ACTCP序列号作为过滤条件，在252”），即可得到全部具有该的数据报文均使用CAPWAP抓包点2捕获的CAPWAP分分片ID的CAPWAP分片。以1602021.05

投稿信箱：**********************

责任编辑：赵志远

故障诊断与处理Trouble Shooting终端电脑发送1500 B的IP分片后，未能有效检测出其结语分组计算，扣除20 B的IP中存在一个（实践中亦可能无线终端快速、大量发送首部和20 B的TCP首部，其为多个）孤立的分片结尾，并无线报文给AP。AP将这些净载荷为1 460 B，被CAPWAP将该孤立分片的结尾与下一报文进行CAPWAP封装、分片分为两个片段，长度分别为个周期（指分片ID字段循环时，因某种Bug会丢失其中1 370 B和264 B（含必要的一次）抵达的分片开头进行的一些分片。CAPWAP协议协议首部）。错误重组。此举导致了在其仅使用分片ID（Fragment

观察过滤结果，可见分片后到达的每一个具有相同分ID）字段确认两个分片间的开头（1370 B）和分片结尾片ID的CAPWAP分片都发生关系，但分片ID字段的表示B）均为成对依次出现了错误重组，进而导致AC发范围过小，在传输中易发生实际环境中不能排除乱序送到有线网络中的分组携带重复。AC仅依据分片ID对到达的情况）。但数据包编了错误的数据载荷。CAPWAP分片进行重组，可能号942 944为孤立的分片结AP丢失CAPWAP分片，与会导致两个拥有相同分片尾，并未有与之对应的分片AC错误重组CAPWAP分片，ID但毫不相关的分片被错开头。从报文抵达时间上看，这两个故障之间的联系即是误地组合在一起，生成了一其与前后两个报文，间隔时“分片”。如能避免终端发送系列TCP校验和错误（载荷间都过长（约3～4秒），在的数据帧被AP分片，则可避数据同样错误）的分组。这传输延迟仅为数毫秒的局域免触发此故障。些错误的分组被送达NAS，因网中，几乎没有“乱序到达”在H品牌AC上，可使用NAS网卡（驱动）的checksum

的可能性。如图3所示。命令“wlan tcp mss 1200”offload功能故障，有概率放进一步检查CAPWAP分片将无线网络中的TCP MSS设行TCP校验和错误的分组，的载荷，可以发现数据包编置为1200 B（实现原理同路最终导致错误的数据被写入号942 944之前的10个分片，由器Dialer接口上的TCP

NAS硬盘，造成上传的文件损及其之后的8个分片，均两MSS相关命令），让终端发送坏。两成对，可确认942 944号为的数据帧不至被分片，即可看似简单的故障现象，可绝对孤立的分片。有效缓解相关的故障症状。能是多个机制共同失效的结以上结果表明，数据包编但该命令具有一定的局限果。在排障中应尽量安排充号942 944对应的CAPWAP分性：它无法控制其他协议的分的交叉测试，避免被单次片开头，已经在AP上因故丢负载长度。这就意味着，如测试的结果误导，忽略了故失（非在空中丢失，因802.11

果AP/AC的故障未能从根本障背后的真正原因。MAC层可保证帧的完整性），（设备软件层面）上解决，其并未转发给AC。他协议在进行大量传输时仍注：本文中所涉及的单位、而AC在收到这些CAPWAP然可能面临类似的问题。品牌名称均为化名。投稿信箱：********************** 2021.05161（264

（