#pfctl -d No ALTQ support in kernel ALTQ related functions disabled pfctl: pf not enabled
#ipfw l 65535 allow ip from any to any
Вроде все чисто.
Что-то борьба за дисциплину и чистоту логов выходит боком. :)
Можешь подсказать с какими ключами tcpdump дампить заголовки?
А я все больше склоняюсь к nodelay и 503. Хотя один образцовый сервер не дает покоя - как-то на нем завелось же все как мне хочется. И limit_req работает и в логи всякие обрезки не падают..
Ушёл, дождался окончания задержки, начал отправлять данные
клиенту, забил tcp'шный буфер на отправку, ушёл дожидаться пока
клиенту из буфера что-нибудь уйдёт. Клиенту так ничего и не
отправилось, соединение было закрыто по таймауту.
Для полноты картины неплохо бы ещё поймать tcpdump подобной сессии
(достаточно просто заголовков, без содержимого пакетов), и
рассматривать вместе с debug log'ом.
> Фича? Конфликт двух настроек? Но вылазит только на "Download Master"? Истина
> где-то рядом.... :)
У вас случайно никаких файрволов сопровождающихся блокировками не
настроено? Очень похоже что где-то по дороге стали просто дропать
пакеты. Я сомневаюсь что вышеописанное поведение свойственно
самому Download Master'у, но вот его неумеренная настойчивость
вполне может вызывать реакцию всяких скриптов следящих за
логами...
