Я не могу передать по FTP (получить) большой файл из Интернета на мою виртуальную машину Linux. Через некоторое время он истекает.
Фактическая ошибка "Не удалось прочитать ответ от управляющего соединения - истекло время ожидания."Эта ошибка возникает через несколько минут после того, как хороший фрагмент файла уже был передан.
Настройка такова:
FTP Client: ncftpget running in Linux on VMWare Player 3.0 FTP Server: somebody else's machine out on the Internet, configuration unknown Guest OS: Ubuntu 8.10 Linux 32-bit, with vmxnet and vmware tools installed. Host OS: Vista 64-bit Network: Linux VM connects to the Internet via Bridged NIC (also tried NAT) FTP Mode: PASVI did find some forum postings mentioning a 2-minute timeout somewhere. But exactly where and how to fix it was not clear. Some troubleshooting steps already tried:
ОБНОВИТЬ Netstat на виртуальной машине Linux и эквивалентная страница администратора на маршрутизаторе DIR-655 показывают, что соединение работает и работает (статус tcp «ESTABLISHED»). Vista вообще не видит соединение, что, я думаю, нормально, если состояние соединения управляется только внутри виртуальной машины.
Вот результат netsh interface tcp show global в Vista, если это полезно:
C:\Users\alex>netsh interface tcp show global Querying active state... TCP Global Parameters ---------------------------------------------- Receive-Side Scaling State : enabled Chimney Offload State : disabled Receive Window Auto-Tuning Level : highlyrestricted Add-On Congestion Control Provider : none ECN Capability : disabled RFC 1323 Timestamps : disabled ** The above autotuninglevel setting is the result of Windows Scaling heuristics overriding any local/policy configuration.
Если вы проходите через 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 раз в минуту независимо от активности в сокете.
Обратите внимание, что клиент ftp может фактически не ИСПОЛЬЗОВАТЬ сообщения поддержки активности. Это то, что приложение должно запрашивать. Если это не удастся, возможно, лучше будет установить другой FTP-клиент. FTP-клиент NetBSD (lukemftp) может быть доступен, и это лучший FTP-клиент командной строки, который я видел на сегодняшний день.
Также возможно, что удаленный конец закрывает соединение из-за бездействия. Если это так, то у него довольно нечеткое представление о реальности. Если указанные выше хаки TCP keepalive не исправят это, либо клиенту придется периодически посылать какую-то команду (NOOP и т. Д.), Либо администраторам FTP-сервера придется изменить свою сторону.
Это может быть любое фильтрующее устройство на пути между вашей виртуальной машиной и FTP-сервером. Большинство брандмауэров (включая домашние маршрутизаторы) имеют таблицу состояний, в которой неиспользуемые сеансы TCP сбрасываются по истечении определенного времени ожидания.
Вы можете изменить сетевой адаптер виртуальных машин в мостовой режим (вместо NAT), чтобы разобраться с ОС хоста. Затем, убедитесь, что ваш FTP-клиент отправляет команды NOOP периодически, чтобы командный канал оставался открытым. Существуют брандмауэры, которые закрывают соединение для передачи данных, если видят, что командный сеанс закрыт. Независимо от того, используется ли соединение для передачи данных или по нему идет трафик ...
HTH,
PEra
Если вы делаете это из командной строки, попробуйте включить «хэш» («двоичный» - это еще один параметр, который я всегда включаю). Это может генерировать достаточно трафика на порту управления, чтобы не допустить истечения времени ожидания.
Для устранения неполадок попробуйте загрузить тот же файл через wget или curl. Я подозреваю, что PEra верна, команды NOOP предотвратят это, и, возможно, их отправят wget или curl.
FTP использует два сокета - один для управления, а другой для данных.
Скорее всего, именно таблицы состояний NAT на виртуальной машине вызывают тайм-аут контрольного соединения из-за неактивности этого сокета.
Вы можете обойти это, включив «Активный FTP» в системе виртуальных машин, что, как мы надеемся, заставит VMware активно наблюдать за сессиями FTP и поддерживать управляющий сокет в рабочем состоянии, пока данные все еще передаются.
Если FTP-сервер - Vista, перейдите к свойствам FTP-сайта и увеличьте время ожидания с 15 минут (по умолчанию). Насколько велик файл, который вы пытаетесь передать?