我无法通过 FTP 将大型文件从互联网传输到我的 Linux VM。一段时间后就会超时。
实际错误是“无法读取来自控制连接的答复 - 超时。“此错误在文件的很大一部分已经传输几分钟后发生。
设置如下:
FTP 客户端:在 VMWare Player 3.0 上的 Linux 中运行的 ncftpget FTP 服务器:互联网上其他人的机器,配置未知 客户操作系统:Ubuntu 8.10 Linux 32 位,安装了 vmxnet 和 vmware 工具。 主机操作系统:Vista 64位 网络:Linux VM 通过桥接网卡连接到互联网(也尝试了 NAT) FTP 模式:PASV我确实在论坛上看到一些帖子提到了 2 分钟超时。但具体在哪里以及如何修复它并不清楚。已经尝试了一些故障排除步骤:
- 我已经从 VMWare Player 3.0 切换到 VirtualBox 3.0.x,但没有成功。
- 我也从 NAT 改为桥接虚拟网卡,但没有成功
更新 Linux VM 上的 Netstat 和 DIR-655 路由器上的等效管理页面均显示连接正常(tcp“已建立”状态)。Vista 根本看不到该连接,我猜如果仅在 VM 内管理连接状态,这是正常的。
以下是输出netsh 接口 tcp 显示全局在 Vista 上,如果它有用:
C:\Users\alex>netsh 接口 tcp 显示全局 正在查询活动状态... TCP 全局参数 ---------------------------------------------- 接收方缩放状态:已启用 烟囱卸载状态:已禁用 接收窗口自动调节级别:高度限制 附加拥塞控制提供程序:无 ECN 功能:已禁用 RFC 1323 时间戳:已禁用 ** 上述自动调整级别设置是 Windows Scaling 启发式方法的结果 覆盖任何本地/策略配置。
答案1
wget
为了进行故障排除,请尝试通过或下载同一文件curl
。我怀疑 PEra 是正确的,NOOP 命令将阻止这种情况,并且 wget 或 curl 可能会发送它们。
答案2
如果您正在通过 NAT,则 NAT 计时器可能会断开您的连接。我在酒店房间里看到过这种情况,在那里我通过 ssh 进入一台机器,但一段时间内无法执行任何操作(有时短至 5 分钟!)
# echo 60 > /proc/sys/net/ipv4/tcp_keepalive_time
# echo 60 > /proc/sys/net/ipv4/tcp_keepalive_intvl
# echo 20 > /proc/sys/net/ipv4/tcp_keepalive_probes
尝试一下。这将导致每分钟在所有 TCP 流上发送一次 keepalive,而不管套接字上的活动如何。
请注意,ftp 客户端可能实际上不使用 keepalive。这是应用程序必须请求的。如果失败,安装另一个 FTP 客户端可能会更好。NetBSD FTP 客户端 (lukemftp) 可能可用,并且是我迄今为止见过的最好的命令行 FTP 客户端。
远程端也可能由于不活动而关闭连接。如果是这样,那么它对现实的认识就相当不准确。如果上述这些 TCP keepalive 技巧无法解决这个问题,那么客户端必须定期发送一些命令(NOOP 等),或者 FTP 服务器的管理员必须更改其终端。
答案3
它可能是虚拟机和 FTP 服务器之间的任何过滤设备。大多数防火墙(包括家用路由器)都有一个状态表,空闲的 TCP 会话会在一定超时后重置。
您可以将虚拟机网卡更改为桥接模式(而不是 NAT),以解决主机操作系统问题。然后,确保您的 FTP 客户端发送 NOOP 命令定期保持命令通道打开。如果防火墙发现命令会话已关闭,则会关闭数据连接。无论数据连接是空闲还是正在传输流量...
HTH,
PEra
答案4
FTP 使用两个套接字 - 一个用于控制,一个用于数据。
很可能是虚拟机上的 NAT 状态表由于该套接字上不活动而导致控制连接超时。
您可以通过在 VM 系统上启用“主动 FTP”来解决此问题,这有望使 VMware 主动监视 FTP 会话并在数据仍在流动时保持控制套接字处于活动状态。