Имитация/создание "битого" пакета (пакета с ошибками)

[nikedeforest]

Задача, послать пакет с одного компа на другой, при этом этот пакет должен считаться пакетом с ошибками, чтобы на него соответсвующим образом среагировало сетевое оборудоавние, а также мониторинговое оборудование. Предполагаю, что таким может быть пакет с неверной контрольной суммой, к примеру. Я по честности не знаю даже в какую сторону посмотреть. Прошу подсказать направление.

[Алексей++]

nikedeforest, делаешь пакет как обычно (данные - любые, хоть RND), затем в уже подсчитанной CRC инвертируешь один любой бит - это будет практически на 100% испорченный пакет

[nikedeforest]

Это ты молодец конечно. Видимо ты знаешь как изменить этот подсчитанный CRC?

[npak]

nikedeforest,

посмотри генераторы пакетов http://sourceforge.net/projects/pacgen/ и http://sourceforge.net/projects/packeth

Я не разбирался, но предполагаю, что они должны уметь генерировать пакеты с различными дефектами.

[Алексей++]

nikedeforest, нет, не знаю ))

[nikedeforest]

npak, я смотрю, выбираю. Только вопрос, если вдруго самому захочется, то это я так понимаю, надо смотреть в сторону raw-сокетов?

[nikedeforest]

Прошу теоретические проблески мои ликвидировать. Рассмотрим семейство протоколов tcp/ip. Этот протокол с гарантированной передачей данных. Для этого применяется механизм контрольных сумм, т.е. если сошлась контрольная сумма, то пакет не битый, если не сошлась, то пакет битый и получившее его устройство подаст запрос на его повторение. А вот дальше непонятка уже. Как я понял, есть контрольная сумма пакета и есть контрольная сумма кадра(фрейма).Как я понял, контрольную сумму пакета нарушить проще, чем кадра (если у кадра е вообще получится нарушить). И тут у меня куча вопросов. Даст ли мне что-то нарушение контрольной суммы именно пакета, а не кадра? Какие устройства среагирует на битый пакет (пошлют запрос на повтор или еще чего), а какие на битый фрейм? Достаточно ли будет ошибиться в алгоритме расчета контрольной суммы пакета при его генерации, чтобы пакет посчитали ошибочным?

[Finch]

Никита, курс молодого бойца по обустройству TCP/IP протокола в книжке занимает минимум 50 страниц.
А так есть несколько уровней работы с пакетом и каждый уровень добавляет свой загаловок. Верхний уровень это твои данные. Тут можно играться как хочеш. Второй уровень добаляет к твоим данным заголовок. В котором описаны длина пакета, тип пакета, контрольная сумма. Третий уровень драйвера. Тут описаны IP адреса,  порты приема и передачи, тип протокола, время жизни пакета, важность пакета и контрольная сумма. и четвертый уровень железа. В Пакет добавляется заголовок состояший только из двух MAC-адресов.
На Уровене драйвера ты можеш програмно изменять некоторые поля, но контрольная сумма подсчитывается самим драйвером.
На Втором уровне можно изловчится менять контрольную сумму.

Теперь расмотрим протоколы.
ARM - протокол самого нижнего уровня. На нем в основном строятся сервисы сетки.
IMAP - Протокол имеет IP адреса, но не имеет портов. Есть несколько направлений использования данного протокола. Обшеизветное, так называемое Echo. На нем в основном работуют такие програмы, как ping и Traceroute.
UDP -  Протокол требует IP адреса и порты. Протокол одностороний и не требует связки. Отослал сообшение. Дошло оно или нет, это протокол не контролирует Максимальная длина отсылаемых данных в пакете вроде чуть меньше 64 килобайт.
TCP - протокол требует IP адреса и порты и также требует связывания серверов. Вот в нем гарантирована доставка. Количество отсылаемых данных практически не ограничено.

Могу выслать на почту тебе книжку по сокетам. Правда есть два досадных минуса. При OCR сделано много опечаток, и под Linux эта книжка. Второй минус не так сушественен. Система команд в сокетах практически индентична.

[RXL]

nikedeforest, битый пакет просто будет отброшен, без разбора контента и каких-либо других действий.

[nikedeforest]

RXL, а чем тогда достигается достоверная доставка? Что будет инициировать повтор битого пакета?
Виктор, маленькая поправочка. IMAP вроде относится к почтовому протколу. Для пинга и прочего ICMP используется.
На остальное позже отвечу.

[RXL]

nikedeforest, для понимания стоит почитать алгоритм работы TCP.

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

На самом деле картина сложнее. Не поленись - почитай теорию.

Пинговать можно чем угодно, главное чтобы вернулся ответ. Просто ICMP echo/reply - стандартный способ, включающий поддержку на уровне IP, без использования вышестоящих приложений.

[npak]

есть переносимая библиотека libpcap, которая позволяет отправлять почти произвольные наборы битов в канальный уровень. Алгоритм работы такой:
1. Сформировать полезную нагрузку IP (пакет транспортного уровня (UDP, TCP и т.д.), пакет ICMP и какой другой служебный протокол)
2. Прикрепить к нему заголовок IP
3. Прикрепить заголовок канального уровня (скорее всего, это окажется Ethetnet или совместимые с ним)
4. отправить непосредственно в канальный уровень.

Но тебе это нужно? Пользуйся генераторами, сэкономишь себе массу сил.

[nikedeforest]

npak, я ищу генератор, понимаю, что так быстрее. НО мне нужен под винду, а твои под линукс. Я нашел под винду один, автор некто Потемкин. http://www.bestprog.ru/1/19/6508/  . Но тут либо я кривой, либо генератор, потому как пакеты он не отправляет, а все время сообщает о какой-то ошибке.
А вот, что я еще нашел. Типа напиши генератор сам. Код готовый. Думаю может его использовать.
http://www.komsoft.ru/pma/gen_packet.htm
Что скажете, согласны ли вы с изложенным там?
А вопросы  меня эти возникли именно из-за того, что есть контрольная сумма фрейма и контрольная сумма пакета.
RXL, алгоритм понял, спасибо. По поводу теории, Network programming for Microsoft Windows пойдет? И что от туда мне в первую очередь колупать? Я пока про простые сокеты читаю.  ВСю по порядку пока нет возможности читать.

[nikedeforest]

ПРограммка Потемкина сыровата, отправляет ICMP-пакеты, но хоть и есть опция  - портить CRC, но она не работает.

[npak]

Контрольную сумму фрейма считать не нужно, она считается автоматически при отправке через libpcap.

Как считать контрольную сумму пакета - см. rfc791, там все написано

[nikedeforest]

Нашел классный мониторинг, в котором есть и генератор - CommView http://www.softkey.ru/catalog/download.php?ID=3031&referer1=softkey_info
Там на 30 дней демо-версия дается, которая не сильно урезана при этом. Так вот он позволяет мне менять контрольную сумму на уровнях не ниже IP. Уровень Ethernet уже не тянет увы. Очень хотелось бы для полноты картины еще и Ethernet менять. Это возможно? И бывают ли такие генераторы?

[npak]

зачем тебе менять фрейм ethernet? такой фрейм будет отброшен карточкой и на IP стек не повлияет.

[nikedeforest]

Именно так. Мне важно узнать отметит ли это прибор мониторинга. Если не отметит, то надо будет думать как самому отследить этот момент.

[nikedeforest]

Вообще, реально ли докопаться до протокола Ethernet? Если реально, то с помощью чего? Есть ли готовые инструменты, которые это реализуют?

[nikedeforest]

Нашел вот что http://www.ndispatcher.com/3downloads/?lang=ru
Он позволяет посмотреть число пакетов, которые сетевой адаптер откинул. И это хорошо.
А по поводу генераторов ... . Полазил по Инету, посмотрел, что-то все Ethernet-генераторы представлены ввиде отдельных приборов, что наводит на смутные сомнения.
А просветите дилетанта, NDIS-драйвер тоже позволяет работать с протоколами не ниже tcp/ip?

[x77]

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

[nikedeforest]

х77, портить контрольную сумму на уровне tcp и ip уже не проблема, CommView в этом нормальнгый помощник и реакции системы на это уже отследили. ПРоблема теперь уровень Ethernet. Но исследование генераторов Ethernet-пакетов привело к выводу, что это подсилу только уже именно приборам, предназначенным для анализа протоколов 6 верхних уровней  (многие и параметры сигнала анализируют), в том числе они содержат в себе функции генерации. Как я понимаю, силами обычного сетевого адаптера это не решить, не вторгнуться в его сферу видимо в данном вопросе.

[x77]

nikedeforest, ну в конце концов можно же в паре переставить местами любые два провода и переобжать (не оверкросс, а именно Data c землёй, например). сеть работать не будет, т.к. на коммутатор придёт всякая мура. вот вам и битые пакеты.

[nikedeforest]

А будут ли там уже эти пакеты? . Там поди в этом случае протокола Ethernet не распознать будет. Но попробовать не долго.

[x77]

nikedeforest, а как ты собираешься на аппаратном уровне отличить "битый пакет" от набора байтов, который вообще не пакет? насколько я понял задачу, там вообще можно подключить на вход электробритву Харькiв, и фтыкать рогами в космос.