Скажи, что не так ? (Гуру TCP - разомнитесь :)

Я не особо разбираюсь в TCP, но, ИМХО, странности начинаются с пакета 179, когда подряд идут ACK, точнее "TCP Dup ACK 175". А потом, начиная с Frame 204, для меня не понятно, 10.1.1.10 делает Retransmission, ему приходит ACK, а он продолжает повторную передачу с увеличением паузы.

$ tcpdump -r ./tcpdump.log
tcpdump: bad dump file format

wireshark тоже не захотел.

md5sum на этот файл сделай и скажи что вышло. Чую, у тебя проблемы с сетью на сервере.

почитал твою тему timed out while sending message body
если у них закрыты icmp, тут никакх не поплящешь.
только менять на своей стороне mss
можешь поставить заведомо маленький, скажем 900, и попробовать.
на линуксе это вроде как через iptables можно сделать.

>md5sum на этот файл сделай

Блин, при закачке нули в файле заменяются на пробелы :( Надо посмотреть настройку сервера для расширений "log".

Используйте ссылку www.prominform.ru/files/tcpdump.rar

Ты пробовал sack отключать?
net.ipv4.tcp_sack

>Ты пробовал sack отключать

Нет пока.

Пока ждал дочку с из кружка - было время вдумчиво покопать бумажную версию протокола :)

Лично мое видение процесса:

Мой хост начинает передачу тела письма SEQ=162 Причем передача идет упреждающими темпами - ACKи начинают запаздывать. Т.е. удаленный хост (сеть ?) "притормаживает" с подтверждениями. Тем не менее WIN клиента не уменьшается - а наоборот растет. Поэтому мой хост не снижает интенсивности передачи - ведь буфер клиента боьшой и он может буферизировать нашу передачу.

Все так и идет - своим чередом, пока на сегменте 175 (по wireshak) не приходит подтверждение ACK для SEQ 101282. Что само по себе не является криминалом (эти данные мы уже давно передали) и в ответ мой хост (10.1.1.10) отдает еще три датаграммы SEQ 161338 (NEXT SEQ 162706) - (разбег ACK в 61424 !неподтвержденных байтов - если правильно считаю).

И тут начинается "интересное". Судя по всему наш клиент делает то что называется "быстрая пвторная пересылка" - fast retransmit (?). И посылает сегменты ACK 179 - 204 с ACK 101282 (получаем дублирование ACK).

В сегменте 204 осуществляется повторная передача сегмента 101282 (NEXT SEQ 102650). Удаленный хост подтвержаает RETRANSMIT ACK ом 105386. Что вобщемто хорошо - подтвержден потерянный пакет и заодно и еще часть ранее переданных данных.

И здесь по всей видимости начинается "засада". Не смотря на то, что клиент уже подтвердил прием данных - мой хост по всей видимости выбирает следующий ACK из "кучи" переданных ранее ACK fast retransmit, думает что его "не поняли" - увеличивает таймаут и опять передает сегмент c SEQ 101282. Клиент его опять подтверждает. И все повторяется снова (ACKи в буфере моего приема еще "не кончились"). Это бы ситуация "рассосалась" бы если не одно НО - величина таймаута с каждой следующей передачей экспоненционально увеличивается - достигает - нескольких минут и тут понятно почему наша почтовая система диагностирует "timed out while sending message body". Лично я ее понимаю :)

Как же "подружить" "кучу DUP ACK" c таймаутами передачи ? Правомерно ли посылать "кучу DUP ACK" ?

>только менять на своей стороне mss >можешь поставить заведомо маленький, скажем 900, и попробовать

Мой MSS тут непричем - - судя по протоколу при передаче тела письма - нам "достаются" только коротки ACKи - которые и так "в любую щель пролезут".

вам - да, а удаленному серверу идут большие пакеты.

> вам - да, а удаленному серверу идут большие пакеты

Не больше тех, что указано в его МSS при "рукопожатии". Из протокола: Сегмент 2. "Их" MSS=1380

посмотрел логи. Походу что-то там не проходит потому что ack=205 пришёл кучу раз от удалённой стороны. Это значит что удалённая стороная не видит пакетов.

Выключи sack и попробуй понизить MTU.

Кстати, пусть те чуваки пришлют свой tcpdump :)

>Правомерно ли посылать "кучу DUP ACK"

После трех DUP ACK - должен наступить режим fast retransmit. НО! В твоем случае это не "куча DUP ACK", а SACKи с одним и тем же ACK-номером, которые советую тебе отключить. Wireshark почему-то не показывает sack в логе твоем, поэтому лучше смотреть tcpdump'ом.

>Выключи sack и попробуй понизить MTU

Выключил sack - и о чудо - передача пошла - письма сали ходить за расчетное от своего объема время ! :) sysctl net.ipv4.tcp_sack=0 Дамп тут: www.prominform.ru/files/tcpdump_ok.rar

Судя по дампу - на DUP ACK теперь мой сервер рееагирует адекватно. Ачто известно плохого про опцию sack (кроме моего отрицательного опыта :) ?

Длииный и не очивидный путь однако у "timed out while sending message body" :)

> Wireshark почему-то не показывает sack в логе твоем

показывает.

2oaealex: что там за картинка в аттаче? Там тока верхний кусок неба скачался :). Это я к тому что когда выкладываешь дамп или логи смотри чтобы ценная инфа не утекла.

>Wireshark почему-то не показывает sack в логе твоем

А Transmission_Control_Protocol->Optons->Sack - это не то ?

> что там за картинка в аттаче? Там тока верхний кусок неба скачался :)

Я предполагал что аттач вызовет интерес :)) Это вид в окресностях Эльбруса :)

>А Transmission_Control_Protocol->Optons->Sack - это не то ?
угу, то. Я имел ввиду твой расшифрованный wiresharkom файл wireshark.out Там почему-то про sack я ничего не нашел.

>Я имел ввиду твой расшифрованный wiresharkom файл wireshark.out Там почему-то про sack я ничего не нашел

Видимо во время экспорта в текстовый вид эта ветка опций не была развернута.