> > Т.е. максимально допустимый номер сегмента для > передачи: > > 762155733+21936= 762177669 > > Нет. ack - это просто случайное число (для первого пакета > случайное), с размером окна никак не связано. Формат Вот именно - для первого, т.е. INITIAL sequence number. А потом - очень даже четкое, ибо обозначает номер последнего принятого фрагмента.
С размером окна оно точно не связано, но эти два значения определяют возможность дальнейшей передачи для сендера...
> журнала tcpdump не полностью помню, некоторые поля мне не > понятны. ПозжЕе постараюсь поконкретней разобраться. Ок.
Че-то совсем у меня крышу рвет.
Виндовая машина (w2k workstation RUS, 192.168.240.21), общается с нетваревым сервером (версия 5.1, 192.168.100.114). На одном из маршрутизаторов, находящихся между ними, стоит файрвол на базе IPFilter (версию назвать не могу, это "вещь в себе", исходников разработчик не прикладывал, а как он изменил стандартные - я не в курсе). Так вот, эта штука периодически отбрасывает пакеты от сервера к станции, которые формально правилам фильтра удовлеворяют (протокол tcp разрешен без ограничений в обоих направлениях). Обращаюсь к разработчику, получаю ответ, что пакет отброшен, так как он выходит за границы окна приема (в терминах tcp).
/* вопрос нафига файрвол вмешивается, если обе стороны передача устраивает пока не рассматриваем */
Если смотреть с точки зрения "классического" tcp, то передающая сторона может посылать данные в пределах (последений ACK)+(размер окна приемника).
Последний ACK 762155733
Окно приемника 21936
Т.е. максимально допустимый номер сегмента для передачи: 762155733+21936= 762177669
Соответственно, файрвол (если он пасет статус соединения на таком уровне), должен был отбросить пакет 11:31:42.731089, поскольку он
начинается с 762180949 (>762177669).
Однако, после него пролетает еще 5 пакетов, и отбрасывается лишь
11:31:42.731642.
Рассматриваемое соединение использует расширения tcp Selective acknowledgment (RFC2018) и Large Window (RFC1323).
Собственно, вопрос. С учетом этих расширений, является ли приведенный выше фрагмент сессии "нормальным" или все-таки имеет место быть выход за границы окна (баг в IP-стеке нетвари)?
У меня подозрение, что размер окна все-таки не 21936, а гораздо больше, с учетом scale option (она определяется при установлении tcp-соединения; к сожалению, сниффер был запущен после начала сессии).
Ну не верю я в столь явный баг в стеке нетвари...
Вопрос к знатокам tcp/ip30.10.03 09:07 Автор: dikiy Статус: Незарегистрированный пользователь
> Если смотреть с точки зрения "классического" tcp, то > передающая сторона может посылать данные в пределах > (последений ACK)+(размер окна приемника). > Последний ACK 762155733 > Окно приемника 21936 > Т.е. максимально допустимый номер сегмента для передачи: > 762155733+21936= 762177669
Нет. ack - это просто случайное число (для первого пакета случайное), с размером окна никак не связано. Формат журнала tcpdump не полностью помню, некоторые поля мне не понятны. ПозжЕе постараюсь поконкретней разобраться.
Вопрос к знатокам tcp/ip31.10.03 07:00 Автор: cybervlad <cybervlad> Статус: Elderman
> > Т.е. максимально допустимый номер сегмента для > передачи: > > 762155733+21936= 762177669 > > Нет. ack - это просто случайное число (для первого пакета > случайное), с размером окна никак не связано. Формат Вот именно - для первого, т.е. INITIAL sequence number. А потом - очень даже четкое, ибо обозначает номер последнего принятого фрагмента.
С размером окна оно точно не связано, но эти два значения определяют возможность дальнейшей передачи для сендера...
> журнала tcpdump не полностью помню, некоторые поля мне не > понятны. ПозжЕе постараюсь поконкретней разобраться. Ок.
подробно о проекте
Анализ криптографических сетевых...
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
