Как определеить, где закрыли порт

[Ian]

Имеется ftp-сервер (у меня под боком), к которому подключаются из другого города. Пару недель назад вдруг подключаться перестали. Имя/пароль сервер принимает, а на попытке загрузить хотя бы список файлов из папки клиент ждет до полного таймаута. Прочий интернет (браузер, почтовик, аська) работает нормально, тамошний программист божится, что их прокси не причем. "Изнутри" нашего провайдера связь нормальная, клиент подключается, файлы передаются.
Цепочка, по которой идет сигнал, ИМХО следующая:
ftp-сервер == мой прокси == мой провайдер == провайдер клиента == прокси клиента == ftp-клиент
Как определить, что и на каком звене цепочки оказалось закрыто? Судя по тому, что из сети провайдера связь нормальная, мой прокси не виноват. Опять же, судя по тому, что имя/пароль принимаются и по результатам запускаемой со стороны клиента команды telnet xxx.xxx.xxx.xxx 21, 21-й порт открыт на всем протяжении цепочки.
Как проверить порты 20 и 11xx по которым идет связь в режиме активного клиента? Через telnet они не подключаются даже изнутри моей локалки. На программиста со стороны клиента надежды нет, максимум, что могу -- попросить оператора что-то запустить на своем "конечном" компе и прочитать с экрана, что получилось.

[BLiTZ]

Попробовать включить пассивный режим?

[Ian]

Если бы... Клиент -- написанная год назад (не мной!) программа, изменить ничего нельзя. Программа работает правильно, что подтверждает запуск тамошним оператором "под моим чутким руководством" ftp.exe. Что там, что там принимает подтверждение о получении логина/пароля, а при попытке get/put или хотя бы dir -- пауза до победного конца...

[DrEvil]

В активном режиме FTP-сервер с порта 20 инициирует соединение с клиентом на выбранный клиентом порт >1024. Стало быть, порты закрыл или сам клиент (включил Windows Firewall, например), или его провайдер. Есть, правда, и еще вариант, http://support.microsoft.com/kb/196271/ru . Если ребята подняли у себя что-то, хапающее много временных портов (DNS сервер от MS забирает сразу 2500 портов, для примера), то клиенту может не хватать.

[Ian]

DrEvil,

порты закрыл или сам клиент (включил Windows Firewall, например)

У клиента XP SP1, права пользовательские, Windows Firewall был отключен, какой-либо другой не установлен, а компа мадам пользователь слегка опасается, поэтому жмет исключительно что покажут
Так что навряд ли.

или его провайдер. Есть, правда, и еще вариант ...

вот мне и хочется проверить более-менее точно. Чтобы знать, к кому в этой цепочке обращаться.

На "радеоне" посоветовали tracert, но он "стучится" по UDP а не по TCP и х.з. по какому порту, а ставить на стороне клиента Linux, чтобы запустить такую расхваливаемую в гугле штуку как tcptracert, естественно, никто не будет.

в связи с этим ищется win32-аналог tcptracert, который не требует инсталляции и работает на "голой" винде (XP SP1) без обязательной установки каких-нибудь дополнительных драйверов/библиотек (чтобы можно было послать один или несколько файлов на сторону клиента по почте, там бы это скопировали в папку, запустили, и сбросили мне копию экрана или какой-нибудь лог для анализа).

[BLiTZ]

http://sourceforge.net/project/showfile ... p_id=88080

tracetcp is a traceroute utility for WIN32 that uses TCP SYN packets rather than ICMP/UDP packets that the usual implementations use, thus bypassing gateways that block traditional traceroute packets. *Now works with XP sp2*

tracetcp host [options]
where host = hostName|ipAddress[:portNumber|serviceName]
if portNumber or serviceName is not present then port 80 (http)
is assumed.