информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Страшный баг в WindowsВсе любят медЗа кого нас держат?
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
 Умер Никлаус Вирт 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / networking
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Вопрос к знатокам tcp/ip 31.10.03 07:00  Число просмотров: 1403
Автор: cybervlad <cybervlad> Статус: Elderman
<"чистая" ссылка>
> > Т.е. максимально допустимый номер сегмента для
> передачи:
> > 762155733+21936= 762177669
>
> Нет. ack - это просто случайное число (для первого пакета
> случайное), с размером окна никак не связано. Формат
Вот именно - для первого, т.е. INITIAL sequence number. А потом - очень даже четкое, ибо обозначает номер последнего принятого фрагмента.
С размером окна оно точно не связано, но эти два значения определяют возможность дальнейшей передачи для сендера...

> журнала tcpdump не полностью помню, некоторые поля мне не
> понятны. ПозжЕе постараюсь поконкретней разобраться.
Ок.
<networking>
Вопрос к знатокам tcp/ip 24.10.03 09:24  
Автор: cybervlad <cybervlad> Статус: Elderman
<"чистая" ссылка>
Че-то совсем у меня крышу рвет.
Виндовая машина (w2k workstation RUS, 192.168.240.21), общается с нетваревым сервером (версия 5.1, 192.168.100.114). На одном из маршрутизаторов, находящихся между ними, стоит файрвол на базе IPFilter (версию назвать не могу, это "вещь в себе", исходников разработчик не прикладывал, а как он изменил стандартные - я не в курсе). Так вот, эта штука периодически отбрасывает пакеты от сервера к станции, которые формально правилам фильтра удовлеворяют (протокол tcp разрешен без ограничений в обоих направлениях). Обращаюсь к разработчику, получаю ответ, что пакет отброшен, так как он выходит за границы окна приема (в терминах tcp).
/* вопрос нафига файрвол вмешивается, если обе стороны передача устраивает пока не рассматриваем */

Вот кусочек лога tcpdump, начиная с последнего ACK от рабочей станции (11:31:42.730605) и до отброшенного пакета (11:31:42.731642):
=== begin tcpdump log ===
11:31:42.730605 192.168.240.21.1065 > 192.168.100.114.524: . ack 762155733 win 21936 <nop,nop,sack sack 1 {762157157:762162120} > (DF)
11:31:42.730728 192.168.100.114.524 > 192.168.240.21.1065: . 762170981:762172405(1424) ack 2322787874 win 19664 (DF)
11:31:42.730848 192.168.100.114.524 > 192.168.240.21.1065: . 762179525:762180949(1424) ack 2322787874 win 19664 (DF)
11:31:42.730968 192.168.100.114.524 > 192.168.240.21.1065: . 762172405:762173829(1424) ack 2322787874 win 19664 (DF)
11:31:42.731089 192.168.100.114.524 > 192.168.240.21.1065: . 762180949:762182373(1424) ack 2322787874 win 19664 (DF)
11:31:42.731221 192.168.100.114.524 > 192.168.240.21.1065: . 762173829:762175253(1424) ack 2322787874 win 19664 (DF)
11:31:42.731328 192.168.100.114.524 > 192.168.240.21.1065: . 762182373:762183797(1424) ack 2322787874 win 19664 (DF)
11:31:42.731360 192.168.100.114.524 > 192.168.240.21.1065: P 762183797:762184247(450) ack 2322787874 win 19664 (DF)
11:31:42.731490 192.168.100.114.524 > 192.168.240.21.1065: . 762180949:762182373(1424) ack 2322787874 win 19664 (DF)
11:31:42.731610 192.168.100.114.524 > 192.168.240.21.1065: . 762182373:762183797(1424) ack 2322787874 win 19664 (DF)
11:31:42.731642 192.168.100.114.524 > 192.168.240.21.1065: P 762183797:762184247(450) ack 2322787874 win 19664 (DF)
=== end tcpdump log ===

Если смотреть с точки зрения "классического" 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/ip 30.10.03 09:07  
Автор: dikiy Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> Если смотреть с точки зрения "классического" tcp, то
> передающая сторона может посылать данные в пределах
> (последений ACK)+(размер окна приемника).
> Последний ACK 762155733
> Окно приемника 21936
> Т.е. максимально допустимый номер сегмента для передачи:
> 762155733+21936= 762177669

Нет. ack - это просто случайное число (для первого пакета случайное), с размером окна никак не связано. Формат журнала tcpdump не полностью помню, некоторые поля мне не понятны. ПозжЕе постараюсь поконкретней разобраться.
Вопрос к знатокам tcp/ip 31.10.03 07:00  
Автор: cybervlad <cybervlad> Статус: Elderman
<"чистая" ссылка>
> > Т.е. максимально допустимый номер сегмента для
> передачи:
> > 762155733+21936= 762177669
>
> Нет. ack - это просто случайное число (для первого пакета
> случайное), с размером окна никак не связано. Формат
Вот именно - для первого, т.е. INITIAL sequence number. А потом - очень даже четкое, ибо обозначает номер последнего принятого фрагмента.
С размером окна оно точно не связано, но эти два значения определяют возможность дальнейшей передачи для сендера...

> журнала tcpdump не полностью помню, некоторые поля мне не
> понятны. ПозжЕе постараюсь поконкретней разобраться.
Ок.
ну что, нету знатоков? :( 28.10.03 12:09  
Автор: cybervlad <cybervlad> Статус: Elderman
<"чистая" ссылка>
1




Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach