tcpdump

Было похожее, с фиреволлом не умеющиим обраббатывать SACKи так же, как SEQ.

Как это можно проверить? Дамп снят с сервера, в качестве фаерволла используется iptables (iptables v1.4.21), причем с настройками из коробки (правила ACCEPT на все, это интранет). Я по началу думал, что проблема на одном из роутеров, но после того, как увидел, сервер после 3х dupack не хочет в фазе фаст ретрансмит передавать потерянный сегмент, мне показалась проблема на самом сервере.

Я не очень хорошо знаю tcp протокол. По sack (картинка внизу), почему sle sre у сегмента под номером 110995 стоят такие большие цифры 1520794823-1520776191, при этом последний переданный сегмент номер 110994 (110993) имеет seq 121767213 (121768581) размером 1368 байт, т.е. эти байты, которые подтверждает sack, вроде еще не передавались?

https://imgur.com/a/JDfVq3I

Ссылка медленно работает, вот это быстрее.

https://ibb.co/cbpnHy

Самый простой способ - отключить поддержку sack-ов,(sysctl net.ipv4.sack=0, наверное), и посмотреть, изчезла ли проблема.

Происходит так(если это оно, дамп смотреть не могу, ибо политика), когда кривой firewall генерирует случайные seq в оба конца, но не умеет транслировать sack-и в соотв. диапазоны. SACK в этом случае похож на пакет из далёкого будущего. Ядро изрядно удивляется, и ведёт себя не пойми как.

Правда, для этого нужен очень старый фиревол.

Спасибо, действительно аналогичная проблема.