我有一个局域网，里面有一台 TP-Link 路由器（AXE5400，3 个月前），一台 Mac Mini 作为 SMB/CIFS 文件服务器（2020 年，macOS Ventura 13.2.1），还有一台 Windows 11 笔记本电脑和一台 Macbook Pro 笔记本电脑（约 2020/2022 年）。文件服务器最近从 Monterey 升级，升级前后都出现了问题。我在 TP-Link Archer C5 上也遇到了同样的问题。
UDP/TCP 很好 - 我可以 ping 一下，执行 HTTP Web 请求，并且可以通过 VNC 连接到文件服务器，没有任何问题。
笔记本电脑使用 WiFi 时经常出现此问题。笔记本电脑使用以太网时，情况会好得多。我不确定我是否在使用以太网时遇到此问题。
Windows 和 Macbook Pro 笔记本电脑经常会在一段时间内无法连接到文件服务器的网络共享，而其他时间则正常工作。所附屏幕截图显示了在出现问题时我的 Windows 笔记本电脑和文件服务器上同时捕获的数据包。
我是数据包分析的新手，但我发现正常连接以 SMB 协商协议请求开始，然后是文件服务器的 SMB2 协商协议响应，然后一切都应该在一系列活动中启动。相反，当问题发生时，它们似乎按如下方式进行：
- TCP 连接已建立，并被文件服务器成功确认。
- 笔记本电脑发送 SMB 协商协议请求
- 文件服务器不耐烦了，发送了一条 QUIC 消息（大概是转移注意力的手段）
- 文件服务器发送 ICMP 端口不可达
- 最终 Laptop 超时并执行 RST
知道发生了什么吗？我尝试过禁用笔记本电脑、文件服务器和 TP-Link 路由器上的防火墙，但似乎没有任何效果。
Windows 笔记本电脑上的 Wireshark，WiFi（192.168.0.92 又名 IntelCor_bc:f3:36）：
文件服务器上的 Wireshark，以太网（192.168.0.41 又名 Rambo.local 又名 Apple_e7:ca:08）：
答案1
事实证明，问题出smbd在 Mac 上充当 SMB 服务器的服务上。它刚刚停止响应流量，尽管该进程在技术上仍处于活动状态（包含在列表中ps）。
客户端和服务器上的数据包分析表明，在 TCP/IP 级别，所有发送的数据包都已收到。在多次运行中，我看到了以下变化：
- SMB1 协商协议请求已被服务器接收，但尚未响应。
- SMB2 协商协议请求已被服务器接收，但尚未响应。
- SMB2 协商协议请求已收到并响应，但服务器收到的后续 SMB 会话设置请求未得到响应。
重新启动 smbd 服务可以暂时解决问题。我仍在研究其根本问题是什么。
ICMP 端口不可达只是个幌子。它是对 QUIC 数据包的响应。QUIC 数据包被发送到端口 443，而 mac 的 TCP/IP 层只是响应说没有任何东西在监听该端口。我仍然认为 QUIC 数据包是客户端由于不耐烦而发送的 - 也许是因为 SMB 出现故障，它正在回退到 HTTP 模式。