ftp.exe не загружает файлы

Question

[JhaoDa]

Привет, Хабр.
Собственно, сабж, но с одним значительным уточнением — не загружает только через ftp.exe и только на одной машине, прочие же ftp-клиенты работают (Filezilla, Total Commander, даже Проводник).
Проверил ещё на двух машинах, подключенных, правда, к другому провайдеру — всё отлично.

Windows 7, белый IP, роутера нет, брандмауэр отключен, стоит Comodo Firewall, но переведен в состояние «Неактивен» (так же проверено и в рабочем режиме, ftp.exe в доверенных, ограничений нет).

Находил похожую проблему, советовали поменять настройки IE — не помогает.
Пробовал переводить в пассивный режим — не помогает.

Запускаю в виде ftp -n -d -s:D:\ttt\ftp.comm, где ftp.comm содержит:

open host.name.ru
USER dummy 123456
put D:\ttt\test.zip
bye

В ответ получаю:

C:\Users\JhaoDa>ftp -n -d -s:D:\ttt\ftp.comm
ftp> open host.name.ru
Связь с host.name.ru.
220 (vsFTPd 2.2.2)
ftp> USER dummy 123456
---> USER dummy
331 Please specify the password.
---> PASS 123456
230 Login successful.
ftp> send D:\ttt\test.zip *** файл в пару килобайт
---> PORT xx,xx,xx,xx,29,78
200 PORT command successful. Consider using PASV.
---> STOR test.zip
150 Ok to send data.
*** проходит минут 5, я нажимаю Ctrl+C, ибо дальше ждать бесполезно
*** если не трогать, то и час висеть будет
Разрыв любых активных подключений...
226 Transfer complete.
ftp> bye
---> QUIT
221 Goodbye. 

Файл на сервере создаётся, но имеет нулевой размер.
Техподдержка показала кусок лога:

Apr 17 20:00:15 vsftpd[8921]: [dummy] OK LOGIN: Client "xx.xx.xx.xx"
Apr 17 20:00:36 vsftpd[8924]: [dummy] OK UPLOAD: Client "xx.xx.xx.xx", "/test.zip", 0.00Kbyte/sec

Куда копать, дорогой хабр?

Answer 1

[Ярослав]

Сделайте дамп трафика и его посмотрите. (под винду — wireshark'ом можно). По идее, после того как ваш FTP клиент послал команду PORT, сервер должен на него законнектится. Посмотрите, есть ли в это время попытки сервера законнектится. Попробуйте просто с любого сервера из мира законнектится на эту вашу машинку (клиент) на произвольный нестандартный порт — вы должны увидеть трафик в wireshark'е. Может быть ваш ISP режет все таки. Или у них (на FTP сервере) особо фашистский файрвол такие исходящие соединения не пропускает.

Answer 2

[S1ashka]

у нас такое было под новый год. со всех хостов заливалось/перезаписывалось, с того где сидели — нет, никаким клиентом
разбудили ночью админа провайдера, благо знакомый — тот тоже в ауте

в общем, машину ребутните

Comments

[JhaoDa]

Уже 3 раза.

[S1ashka]

давайте дальше
сеть по проводу идет? на семерке есть разделение на домашние\общественные сети — они относятся к брандмауэру, но косяки с ними случаются

другие файлы также не отправляются? а не с диска D, а с С?
А файлы в это время другим процессом не используются?
а бинарный режим принудительно включить?

[JhaoDa]

Никакие, ниоткуда, любого размера. От смены режима толку нет. Естественно, файл не используется.

[S1ashka]

для чистоты эксперимента снести фаерволл или загрузиться в безопасном режиме с поддержкой сети попробуйте

[JhaoDa]

Comodo был отключен полностью, безопасный режим был испробован — эффект нулевой.

[S1ashka]

слейте бинарник фтп.ехе с другой машины и запустите из другого места

[JhaoDa]

Пробовал бинарник другой версии с другой машины — эффект нулевой. Запустить из другого каталога не можно, у него какие-то зависимости, узнать их не получается.

Answer 3

[Владимир Дубровин]

Дайте команду PASV перед PUT, вам удаленный сервер это советует. Скорее всего, где-то прикрыт активный FTP, может быть даже и на удаленном конце.

Comments

[JhaoDa]

Пробовал переводить в пассивный режим — не помогает.

Делал так:

literal PASV
literal STOR D:\ttt\test.zip

[Владимир Дубровин]

Тогда проверяйте сьедующее:
1. Параметр MTU на локальной машине, особенно если используется PPPoE или PPTP, возможно у вас проблема blackhole router — и это наиболее вероятный вариант в том случае, если загрузка файлов с удаленного сервера у вас работает. В большинстве случае можно проверить через ping -l 1500 ftp.server.address
2. Состояние службы alg (Application layer gateway, по-русски это что-то типа служба шлюза приложений). Если фаервол в Windows отключен как служба — alg лучше тоже выключить. Если фаервол работает — alg обязательно надо включать.
3. Антивирусы и прочие программы перехватывающие трафик — есть?

[JhaoDa]

Кхм… вы бы прочитали вопрос еще раз.

[Владимир Дубровин]

Я почитал, Вы не указали как именно отключен брандмауэр и есть ли что-то помимо Комодо. Кстати, перевод фаервола в неактивное состояние не всегда отключает перехват трафика. Но в Вашем случае наиболее вероятен первый вариант. Попробуйте на загрузке файла менее 1 КБ, если она пройдет, то проблема точно в MTU.

[JhaoDa]

MTU влияет на подключение в целом. Не может же быть так, что несколько ftp-клиентов с неправильным MTU работают, а ftp.exe — нет?
Никакого PPPoE или PPTP, обычная статика. Брандмауэр выключен как служба, ALG тоже.

[Владимир Дубровин]

Может быть, все зависит от того, как буферизация данных организована в FTP-клиенте, грубо говоря буффер какого размера передается в send().
Но проверить не сложно — если маленькие файлы на сервер грузятся, то проблема именно с прохождением больших пакетов.

[JhaoDa]

Никакие файлы не грузятся, даже 67 байт размером.

Answer 4

[JhaoDa]

Вот что показывает Wireshark:

FTP	105	Response: 200 PORT command successful. Consider using PASV.
FTP	69	Request: STOR test.zip
TCP	60	ftp > kjtsiteserver [ACK] Seq=129 Ack=73 Win=14720 Len=0
FTP	76	Response: 150 Ok to send data.

и тут же
FTP	78	Response: 226 Transfer complete.
TCP	54	kjtsiteserver > ftp [ACK] Seq=73 Ack=190 Win=8004 Len=0

Comments

[Владимир Дубровин]

А через DATA-connection что идет?

[JhaoDa]

Ничего.

[Владимир Дубровин]

Т.е. оно даже и не устанавливается или по нему данные не идут?
Судя по
Response: 226 Transfer complete.
и файлу нулевого размера на сервере, сервер получил входящее соединение, но оно тут же было закрыто. Попробуйте в свойcтвах сетевого соединения отключить компоненты Comodo (там должен быть что-то типа COMODO Internet Security Firewall Driver).

[JhaoDa]

Именно там и отключал.

ftp.exe шлёт запросы через порт 1153, для подключения предлагает порт 1154, но этот порт нигде не фигурирует в логах Wireshark'а.

local 	server	FTP	79	Request: PORT xx,xx,xx,xx,4,130 *** port 1154
server	local 	FTP	105	Response: 200 PORT command successful. Consider using PASV.
local 	server	FTP	69	Request: STOR test.php
server	local 	TCP	60	ftp > c1222-acse [ACK] Seq=129 Ack=74 Win=14720 Len=0

***через 20 секунд
server	local 	FTP	76	Response: 150 Ok to send data.
server	local 	FTP	78	Response: 226 Transfer complete.
local 	server	TCP	54	c1222-acse > ftp [ACK] Seq=74 Ack=175 Win=8018 Len=0
*** через 5 минут
server	local 	FTP	68	Response: 421 Timeout.

[Владимир Дубровин]

Только там? Так ни в коем случае не надо делать. Это NDIS-драйвер, а помимо него есть еще TDI и WFP. Если отключен только NDIS драйвер — результат может быть непредсказуем, необходимо отключать защиту в самом Comodo.

[JhaoDa]

Да везде отключал.