找回密码
 加入我们
搜索
      
楼主: darkclown

[网络] SMB是可能静默数据损坏的,同步重要文件务必开启校验(加密)

[复制链接]
发表于 2022-12-1 11:10 | 显示全部楼层
这年头,真是防不胜防了
发表于 2022-12-1 11:16 | 显示全部楼层
另外,我发现如果内存不稳定,大容量文件也会造成某些错误。我在某笔记本上制作10GB的ISO文件,里面的文件总是会随机文件损坏。源文件是好的。
但是WINDOWS内存测试都是好的,也不会蓝屏,没有报错。
最后看了知乎的某帖子,换了内存后解决此问题。
从此,我就开始留意ECC了
发表于 2022-12-1 11:24 | 显示全部楼层
本帖最后由 Juzi丶 于 2022-12-1 11:27 编辑

开启SMB加密传输文件出现错误中断.png
开启SMB加密传输文件出现错误然后直接中断

没事干整点测试
发表于 2022-12-1 14:27 | 显示全部楼层
Juzi丶 发表于 2022-12-1 10:33
楼上很多人真是无知者无畏的样子...
可能没见过SMB开了加密之后传输故障主动报错和比如不开加密传一个图直 ...

开了确实能知道出问题 但解决不了问题

很多人的硬件情况确实不会碰到问题
发表于 2022-12-1 14:55 来自手机 | 显示全部楼层
Juzi丶 发表于 2022-12-1 11:24
开启SMB加密传输文件出现错误然后直接中断

没事干整点测试

别超频了,设备正常几百t,没问题的,设备不行开校验解决的也只是网路上的问题,端到端再校验一次错了能报告,你平时要是传十几g都出现数据异常,很明显有哪个环节异常导致,这论坛爱超频,很多人平时本地copy文件估计都hash不一样了也没发现
发表于 2022-12-1 15:44 | 显示全部楼层
瞅了一眼WIN10 SMB加密的是不是高级网络设置的128位加密好像是默认开的,还是在哪开
发表于 2022-12-1 21:15 | 显示全部楼层
ander22 发表于 2022-12-1 15:44
瞅了一眼WIN10 SMB加密的是不是高级网络设置的128位加密好像是默认开的,还是在哪开 ...

那个是身份验证加密,不是SMB数据加密。。。
发表于 2022-12-1 22:19 | 显示全部楼层
jyjs3993 发表于 2022-12-1 21:15
那个是身份验证加密,不是SMB数据加密。。。

啊这 ,看看哪里开去
发表于 2022-12-1 23:55 | 显示全部楼层
赶紧去看看怎么开SMB数据保护……
发表于 2022-12-2 02:46 | 显示全部楼层
好了跟楼上坐等看看有谁能教教WIN10怎么开
发表于 2022-12-2 03:11 | 显示全部楼层
Juzi丶 发表于 2022-12-1 11:24
开启SMB加密传输文件出现错误然后直接中断

没事干整点测试

只碰到过不开100%炸,开了解决,最后结论链路问题,开也会炸么
这年头是要回归两头传完校验才能保真了么
发表于 2022-12-2 07:14 | 显示全部楼层
本帖最后由 hlc1134 于 2022-12-2 07:20 编辑

感觉最可能是路由器问题。不知道lz在哪儿?是用的att还是spectrum 的ISP还是其他的?运营商给的路由器是个黑盒,里面会加很多他自己的东西,比如广告分析之类的。这种addons都非常非常不稳定。反正我用att的光猫问题挺多,最后我自己挂了一个asus路由器,运营商的路由器走透明模式后就很稳定。

其实可以在amazon很便宜买一个交换机,或者买一个大牌的路由器(如果lz只想用无线网),然后完全绕开运营商的路由器测试一下。

我今天用家用设备测了一下,PC和NAS互传,有线连接,中间经过了2个交换机,还有链路聚合,SMB强制开启加密,传了500G东西,没有报错。

反过来说,如果smb经常出错,然后开加密模式可以检测出传输错误然后自动报错。那就会有很多人收到smb的传输错误。这样早就炸开锅了,smb也不会活到现在。
发表于 2022-12-2 08:13 来自手机 | 显示全部楼层
第一,smb如果按楼主测试,就这几下就都出错那问题就大了。这个东西都多少年了的技术
第二,就那英特尔无线网卡,你指望拿来正经干活?
第三,还不如找找硬件问题,你拿别的机器和设备测试测试?
发表于 2022-12-2 08:27 | 显示全部楼层
我曾经有一个神奇的USB有线网卡
正常上网没问题
SMB传东西就会很大概率出错(典型的,几百兆的zip文件拉过来就打不开)
但是ftp传就可以
发表于 2022-12-2 08:34 | 显示全部楼层
皛羽控 发表于 2022-12-1 08:27
什么是静默损坏,先查查再用行不行?回到这个损坏问题我建议是更换硬件设备或者传输过程是否有干扰来排查, ...

不是说smb协议有问题
而是说smb不抗干扰
在硬件有瑕疵的时候不报错
发表于 2022-12-2 10:37 来自手机 | 显示全部楼层
本帖最后由 皛羽控 于 2022-12-2 10:38 编辑
tedsun 发表于 2022-12-2 08:34
不是说smb协议有问题
而是说smb不抗干扰
在硬件有瑕疵的时候不报错


很多传输都不抗干扰要么为什么要有些加强的措施比如内存还有ecc,具体到SMB你也可以开启加密啊。
发表于 2022-12-2 10:44 | 显示全部楼层
Juzi丶 发表于 2022-12-1 11:24
开启SMB加密传输文件出现错误然后直接中断

没事干整点测试

这是什么原理呢?SMB不会自动坏包重传么?
不管怎么说,主动报错要比默默传个坏文件好多了
发表于 2023-5-4 17:47 | 显示全部楼层
看到撸主文中说网络环境无线网卡AX200……什么意思,难到是通过无线网络SMB共享数据的?
发表于 2023-5-4 19:42 来自手机 | 显示全部楼层
哈哈 xswl 无线网卡当服务器?
发表于 2023-5-4 20:43 | 显示全部楼层
没遇到过,pt 几十T 从nas传出来,稳如老狗
发表于 2023-5-4 22:15 来自手机 | 显示全部楼层
FelixIvory 发表于 2022-11-28 14:25
归档了,这个帖子我有印象。给文件加netgear的字头(字尾),帖主给网件反馈,当时就修复了。 ...

虽然是很久前的帖子,还是回复一下。

当年臭名昭著的网件r7800传文件损坏事件,我也是受害者之一。这个问题虽说只发生在ap mode下,但传文件错误率太高导致ap mode完全不可用。而且这个bug根本不是报告了马上就修了,而是拖了三四年之久,只不过之前chh的帖主发现问题晚网件已经快修好了。

可能是网件自己也觉得丢人,现在自家论坛上关于这个事件的讨论基本也都归档了,但外网上还留了一些零零星星的讨论。
https://www.snbforums.com/threads/r7800-data-corruption-when-in-accesspoint-mode.54744/

说起来我那台r7800也是命运多舛,本来就是r7500功能造假批量召回后换回来的,后来发现传输错误根本没法用,等后来bug终于修好的时候这型号都已经淘汰了。
发表于 2023-5-4 23:42 | 显示全部楼层
mark一下,以防万一我也在群晖上开启smb加密吧
发表于 2023-5-5 01:49 来自手机 | 显示全部楼层
darkclown 发表于 2022-11-27 22:32
应该是我这边某一个环节错误率大而没被修正导致的,你那边应该不好观察到。。。

因为我这边做实验也比较 ...

中间加个交换机,排出路由。
 楼主| 发表于 2023-5-6 18:55 | 显示全部楼层
本帖最后由 darkclown 于 2023-5-6 19:26 编辑
zhao137314 发表于 2023-5-4 19:42
哈哈 xswl 无线网卡当服务器?


有线错误率也不是0,更何况这么高的错误率可能还是固件问题导致的,谁也说不好哪天会遇到,smb一个网络文件传输协议,没校验日积月累导致人文件损坏没问题?

xswl,你哪天网上支付他给你来个http传输,内容也不校验,支付多个0是不是也是你用无线的锅?
发表于 2023-5-6 19:25 | 显示全部楼层
按道理来讲,802.11帧的CRC校验不至于这么脆弱呀,这锅无线链路真背不了吧,我更倾向于是路由器加料了
发表于 2023-5-6 19:33 | 显示全部楼层
mark下,这个错误率感觉有点吓人
发表于 2023-5-6 22:06 | 显示全部楼层
本帖最后由 葱花鱼 于 2023-5-6 22:10 编辑

https://www.samba.org/samba/docs ... .html#SERVERSIGNING
虽然是samba的文档,但是根据描述在SMB 2.0以上server signing是默认协商开启的,相比于server smb encrypt选项,这个才是确保文件完整性的本职功能。

你可以试试通过Wireshark抓包分析一下看看Signing Enabled是不是为1,如果数字签名正常启用,理论上应该不会发生这样严重的文件数据错误才对。
您需要登录后才可以回帖 登录 | 加入我们

本版积分规则

Archiver|手机版|小黑屋|Chiphell ( 沪ICP备12027953号-5 )沪公网备310112100042806 上海市互联网违法与不良信息举报中心

GMT+8, 2024-9-20 06:28 , Processed in 0.017455 second(s), 6 queries , Gzip On, Redis On.

Powered by Discuz! X3.5 Licensed

© 2007-2024 Chiphell.com All rights reserved.

快速回复 返回顶部 返回列表