О случае, когда у IP-пакета TTL=0

imho никакой

imho маршрутизатор не пропустит такой пакет

Ну и я думаю, что не пропустит, но может сам добавит до приемлемого уровня, или что-то такое.

Просто фраза запомнилась, а поскольку сам не допер, решил спросить :)

Я об этом - http://www.linux.org.ru/jump-message.jsp?msgid=700132

>, но может сам добавит до приемлемого уровня,

зачем? отпадает смысл существования ттл тогда.

... хотя послушаю мнения гуру :)

> В каком-то обсуждении oxonian писал, что при умышленной установке
> на шлюзе TTL в ноль ничего работать не будет, но вообще - все
> зависит от следующего маршрутизатора.

я так понял что они обсуждали установку TTL=0 на клиенте, а не
на шлюзе. отсюда вижу ваше непонимание.

мое imnsho:

выставление TTL=0 на шлюзе _никак_ не повлияет на трафик _через_
этот шлюз, просто потому что этот пакет идет не от него, а от
клиента. он либо уменьшит TTL этого пакета на 1 или оставит его
(намек на net.inet.ip.stealth=1 в FreeBSD)...

выставление TTL=0 на клиенте действительно зависит от первого
маршрутизатора. если там используется что-то наподобие ip stealth,
то пакет пройдет через него,.. короче говоря он не пройдет первый
маршрутизатор, который уменьшит его TTL.

btw, я только что протестил установку TTL=0 на шлюзах с
OpenBSD 3.6 и FreeBSD 4.11...

естественно, никакого эфекта на проходящий трафик и...
я недописал в прошлый раз, сетевые приложения с этого
шлюза уже не работают с хостами за пределами других
маршрутизаторов... ну это логично :)

ой, а тут появились гуру? Мне тоже интересно, что они скажут. ж)

Когда я говорил, что все зависит от близлежащего маршрутизатора, рассуждение мое было таким:

- пусть у нас есть маршрутизатор, который сначала уменьшает TTL, а потом на него смотрит.
- пусть для операции вычитания, он помещает текущее значение (0) в память, например, как двухбайтное знаковое слово (00000000 00000000 в двоичном представлении).
- пусть отрицательные числа в архитектуре маршрутизатора хранятся дополнением до двух.

Тогда, выполнив вычитание, получим -1, которая в двоичной форме хранится как 11111111 11111111, и взяв младший байт увидим, что он не равен нулю, засунем значение 255 в TTL и передадим его на следующий маршрутизатор.

Мне трудно судить, насколько фантастическим является такой сценарий, но вцелом, подобное развитие событий не исключено, поскольку обычно маршрутизаторы не ожидают прихода пакетов с TTL 0.

Ага, т.е. как я понимаю, речь шла о том, что в общем и целом это возможно, но...

Спасибо.

> поскольку обычно маршрутизаторы не ожидают прихода пакетов с TTL 0.

что значит не ожидают, это их главная задача сбрасывать пакеты с TTL == 0 по RFC! :) Хватит тут уже сказки выдумывать. Возмите сетевой стек и проверьте.

> Когда я говорил, что все зависит от близлежащего маршрутизатора, 
> рассуждение мое было таким:

удасуживайся прочитать собственно вопрос:

> В каком-то обсуждении oxonian писал, что при умышленной установке
> на шлюзе TTL в ноль ничего работать не будет, но вообще - все 
> зависит от следующего маршрутизатора.

подчеркну для одаренных:

> установке на _шлюзе_ TTL в ноль

ты же говоришь про хост. как будет работать маршрутизатор
с такими пакетами? отбрасывать, и это указано в RFC.
то что маршрутизатор будет отнимать от нуля еденицу а потом
проверять говорит только о кривой реализации ПО маршрутизатора.

cu.

> удасуживайся прочитать собственно вопрос:

;)

я, в общем-то, имею привычку помнить, о чем я говорил... Но забавно, спасибо ;)))

> что значит не ожидают, это их главная задача сбрасывать пакеты с TTL == 0 по RFC! :) Хватит тут уже сказки выдумывать. Возмите сетевой стек и проверьте.

Ой, Толя, мне ли нужно объяснять тебе про _должны_ и _делают_?

Давай мы не будем бессмысленно дискутировать? Я привел пример, который имел ввиду. Да, это говорит о некорректной реализации маршрутизатора. Ты что, никогда багов не видел? А я видел, когда TTL сначала вычиталась единица один раз, а потом, если направление ветра навстречу пакету, то еще раз.

Заметь, что по STD5 TTL - это не число хопов, а число секунд на обработку пакета. Поэтому маршрутизатор, который вычитал больше единицы вполне соответствовал STD.