On Mon, Jul 15, 2013 at 01:09:20PM +0400, Eugene Berdnikov wrote: > On Mon, Jul 15, 2013 at 11:59:30AM +0300, Hleb Valoshka wrote: > > On 7/15/13, Hleb Valoshka <[email protected]> wrote: > > >> Думаю, что утверждение о корреляции бага с клиентским tcp_rmem может > > >> быть ошибочным, а "прикол" -- случайным выбросом на малой статистике. > > > > Картина чуток прояснилась: с дефолтными настройками tcp_rmem клиент > > посылал SYN c размером окна 5840<<7, теперь -- 5840<<4. В результате > > от удалённой стороны за раз приходит меньшее количество пакетов: 4 > > против 7, и багу в трекере нет возможности проявиться. Я наверное > > упустил в передыдущих письмах, хотя из дампов понятно, что этот шлюз с > > snat, т.е. его внутреннее состояние сложнее, что у простого шлюза, и, > > возможно, пакеты ack также влияют на это состояние, но это опять же, > > надо копаться в исходниках. > > 5840<<4 = 93440 > > 1500*4 = 6000 что много меньше 93440 > > Я уже писал, что последовательности пакетов должны быть идентичны, > потому что 1. даже десятка пакетов не хватит для заполнения окна, > 2. шлюзу окно транзитной коннекции должно быть абсолютно безразлично, > независимо от наличия snat/dnat.
Вы меня запутали, чушь написал... :( 5840 -- это немасштабированный размер окна в SYNe, а скейлинговый фактор применяется к значениям win у следующих пакетов. -- Eugene Berdnikov -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
