这是一个创建于 1331 天前的主题，其中的信息可能已经有所发展或是发生改变。
PS D:\test> CertUtil -hashfile "Z:\series\生活大爆炸 (2007)\Season 1\生活大爆炸 - S01E01 - 试播集.mkv" md5 MD5 的 Z:\series\生活大爆炸 (2007)\Season 1\生活大爆炸 - S01E01 - 试播集.mkv 哈希: 3b7a7b9379e0bc057b7d4a3f574dc10e CertUtil: -hashfile 命令成功完成。 PS D:\test> CertUtil -hashfile "Z:\series\生活大爆炸 (2007)\Season 1\生活大爆炸 - S01E01 - 试播集.mkv" md5 MD5 的 Z:\series\生活大爆炸 (2007)\Season 1\生活大爆炸 - S01E01 - 试播集.mkv 哈希: 23bdbbd2e1feafebcd63d40fbd3eb359 CertUtil: -hashfile 命令成功完成。 PS D:\test> 网上查了下，有人说是 samba 协议加密的问题，但应该只是在传输过程中吧，不然用 samba 做备份同步时怎么判断是否是同一个文件
试了下用 JPG 图片，是没有不同的 MD5 的
samba 服务是部署在 debian 系统，应该和这个没有关系吧 现在没有什么思路，请大佬指导一下
 | 1 jtshs256 2022-02-20 17:21:28 +08:00  1 |
 | 2 pxx OP @jtshs256 表象和帖子一样，全部视频被污染了，但我用的不是网件，有几个牌子的路由做 AP ，但 asus 的是开了 AP 模式的，AC 是软路由，工控机刷的 LEDE ，我按这个思路查查，感谢 |
 | 3 duke807 2022-02-20 18:34:21 +08:00 via Android @jtshs256 真是的，用 IPv6 可以避免吧，因路由器不需要重新打包 TCP/UDP 包，被改可以通 checksum 查出。 |
 | 4 ysc3839 2022-02-20 18:41:38 +08:00 via Android @duke807 IPv4 也不需要吧？而且现在大多数网络设备都不检查 checksum 了，都是让上层协议(如 https)来检查 |
| 5 duke807 2022-02-20 18:55:01 +08:00 via Android @ysc3839 ipv4 不是一段要走 NAT ，需要修改 TCP 和 UDP 包的端口，改完之後肯定要重新算 checksum ，那新算的 checksum 正好和被改的匹配上了，致接收者查不出。 家庭 /公司部走 IPv6 避免了 NAT 的，效率更高。 |
| 6 duke807 2022-02-20 19:03:16 +08:00 via Android @ysc3839 最底的以太包肯定查校 IPv4 包有校，IPv6 包有校，依靠以太的校就了，少，增加效率 UDP 的包的校是配合 IPv4 的候可（主流系默都是校的），配合 IPv6 的候必 TCP 包的校都是必 是 samba 不健，我一直不怎喜 samba ，其它的 ssh-fs 等，肯定不有 |
 | 9 wanguorui123 2022-02-20 19:43:47 +08:00 先排查下网络设备问题还是 SMB 协议的可靠性问题 |
 | 10 Buges 2022-02-20 21:10:35 +08:00 via Android 你先 ssh 上去算一下文件原本的 hash |
| 11 pxx OP 我用网线直连主路由，一样会有这样的问题，基本可以排除 AP 的问题 到 samba 服务器去 md5sum 是没问题的 我把 700M 的 ideaIU-2020.3.3.exe 拷贝到 samba 服务器，再拷贝回本机，MD5 变了 所以现在的问题的是从 samba 服务器拷贝大文件到本地 MD5 就会变化，小文件不会变化 换了机器换了 CLIENT 问题依旧，可能是 samba 服务的问题？ |
| 14 pxx OP @msg7086 怎么测试，现在用另外一个 nas 上部署 samba 服务是没问题的，现在初步结论应该是 samba 服务的硬件问题导致 |
| 16 pxx OP @msg7086 用 U 盘跑 memtest 进入引导后一直黑屏，不知怎么回事。后面我直接换了一条内存，也没解决问题，可以排除内存的问题 |
| 17 pxx OP 排除下来最后发现是网卡的问题，谢谢大家 |
Select Language