brovy@n
Гость
|
|
« Ответ #120 : 22-04-2006 17:00 » |
|
Да уже допетрил........ Спасиб ---------------------- Просто ради интересу: где сервак находится, на котором этот сайтец хостица? а то у меня ужо 3:57, только a.m. и уже 23 число!!!(типа пасха)
|
|
|
Записан
|
|
|
|
brovy@n
Гость
|
|
« Ответ #121 : 22-04-2006 17:00 » |
|
P.S. На Солдатова только что наткнулся
|
|
|
Записан
|
|
|
|
Finch
Спокойный
Администратор
Offline
Пол:
Пролетал мимо
|
|
« Ответ #122 : 22-04-2006 18:47 » |
|
Просто ради интересу: где сервак находится, на котором этот сайтец хостица? а то у меня ужо 3:57, только a.m. и уже 23 число!!!(типа пасха)
Хотя это оффтоп. Но Сервер стоит в Москве и время Сервера -2 часа GMT. Чтобы у тебя показывалось нормальное время, ты должен сам в своих настройках профиля настроить временное смешение. Секция называется "Внешний вид форума". Пункт "Time Offset".
|
|
|
Записан
|
Не будите спашяго дракона. Джаффар (Коша)
|
|
|
aks68
|
|
« Ответ #123 : 22-04-2006 23:06 » |
|
Спасибо за совет. Насчет MPSend и MPSendPackets, то на сколько я понял, первая используется при отправке одного пакета, а вторая отправляет пакеты из массива. Вро порт, так это я именно про входящие. Вот я что и спрашивал - не пойму точно когда Receive, а когда Send. В документации я где-то вычетал, что для, например, фильтрации можно использовать как первую, так и вторую (т.е. как в модуле минипорта непосредственно перед отправкой, так и в протоколе перед получением). Вот что происходит при принятии пакета? Какая последовательность функций? Receive -> обработка -> Send ?
Добрый день! 1. Насчет MpSend (MiniportSend) и MpSendPackets (MiniportSendPackets) правильно - Send шлет единичный пакет, а SendPackets массив пакетов. К слову сказать SendPackets так-же может послать единичный пакет, если его 3-й аргумент NumberOfPackets установить равным 1. Однако здесь нужно отметить, что обе эти функции - колбэки NDIS-а и только NDIS решает какую из них когда дернуть. В описании функции MiniportSend сказанно, что MiniportSendPackets доминантная, и что в случае, когда зарегистрированны обе функции NDIS будет вызывать только MiniportSendPackets. Наверное по этому в последних версиях Пастру ее (MiniportSend) вообще незарегистрировали. 2. В NDIS существует 2 независимых потока данных (потока в смысле flow, а не thread ) : ВХОДЯЩИЕ (inbound)пакеты следуют из внешней сети через сетевую карту и драйверы к приложению, а ИСХОДЯЩИЕ (outbound) пакеты следуют от приложений через драйверы наружу. С целью упростить описание я вначале приведу схему взаимодействия Miniport и Protocol драйверов без участия Inter Mediate Driver, а затем вместе с ним. Путь входящего пакета (без IM). В тот момент, когда сетевая карта получает данные "снаружи", она тем или иным образом уведомляет об этом минипорт, который в свою очередь преобразует кадр пакета (например Ethernet) в абстракцию используемую NDIS-ом (уже упомянутый здесь NDIS_PACKET) и затем сигнализирует об этом NDIS-у посредством функции NdisMIndicateReceivePacket либо NdisMxxxIndicatrReceieve (в случае Ethernet используется ф-я NdisMEthIndicateReceive). В свою очередь NDIS определяет все драйверы уровня протокола (Protocol Drivers) привязанные к данному минипорту, и для каждого по очереди вызывает их колбэки ProtocolReceive или ProtocolReceivePacket. Таким образом управление по обработке пакета передается в Protocol Driver, который как правило копирует пакет в свой пул данных и затем обрабатывает его как было задумано автором... Разница между ProtocolReceive и ProtocolReceivePacket в том, что ProtocolReceive получает не весь пакет, а только его заголовок и небольшую часть пакета (look ahead buffer) позволяющие быстро определить находится-ли данный пакет в "области интересов" данного Protocol Driver-a. В случае "да" производится "докачка" пакета спомощю ф-и NdisGetReceivedPacket либо чего-то другого и его последующая обработка, в противном случае пакет игнорируется путем возврата статуса NDIS_STATUS_NOT_ACCEPTED. Путь исходящего пакета (без IM). В тот момент, когда пакет готов к отправке Protocol Driver вызывает ф-ю NdisSend либо NdisSendPacket сигнализируя таким образом NDIS-у, который, основываясь на своих внутренних алгоритмах, определяет вызвать ему MiniportSend либо MinioirtSendPackets и далее управление передается в Miniport Driver... Описание взаимодействия с IM, я представлю позже - уже поздно иду спать С уважением, Акс.
|
|
|
Записан
|
|
|
|
new_s
|
|
« Ответ #124 : 23-04-2006 00:09 » |
|
а не могли бы вы объяснить(я думаю смый интересный вопрос) как распотрошить пакет?
|
|
|
Записан
|
|
|
|
aks68
|
|
« Ответ #125 : 23-04-2006 23:48 » |
|
а не могли бы вы объяснить(я думаю смый интересный вопрос) как распотрошить пакет?
Добрый день! В начале я хотел-бы закончить с примерами прохождения пакета, раз уж начал... Хотя непредставляю, что там из пакета такого можно "выпотрашить"? Ну тип пакета, IP-адреса, TCP-порты... что-то еще? С уважением, Акс.
|
|
|
Записан
|
|
|
|
aks68
|
|
« Ответ #126 : 24-04-2006 00:02 » |
|
Продолжение про пакеты... Существуют 2 способа подключения IM драйвера: 1. В виде фильтра - при этом соотношение адаптером MP и виртуальным адапрером IM 1:1. Данная схема подходит только для фильтрации пакетов. 2. В виде мултиплексора - при этом соотношение адаптером MP и виртуальным адапрером IM 1:N / N:1. Данная схема подходит для баланса нагрузки. Нас интересует 1й способ. При подключении IM драйвера он помещается между драйвером протокола и драйвером минипорта. При этом, что-бы ненарушать порядок взаимодействия, IM драйвер реализует в своей верхней части (upper edge) ф-ции минипорта - для взаимодействия с вышерасположенным драйвером протокола, а в нижней части (lower edge) ф-ции протокола для взаимодействия с низлежащим драйвером минипорта. Порядок взаимодействия частей определяется с помощю связывания компонент взаимодействия, в порядке определяемом при установке IM драйвера. Помимо этого в процессе связывания в области IM драйвера создается виртуальный адаптер для нормальной работы с вышерасположенным драйвером протокола. Путь входящего пакета (с IM). 1. Сетевая карта получила фрейм Ethernet пакета и MP преобразовал его в NDIS_PACKET 2. MP сигнализирует NDIS-у (так-же, как и в случае без IM) 3. Т.к. адаптер MP связан с "протокольным" концом IM, NDIS вызывает PotocolReceive/ProtocolReceivePacket зарегистрированные IM-ом, и пакет поступает в IM 4. Вначале IM-овский ProtocolReceive(Packet) ведет себя аналогично PD-шному, т.е. анализирует полученые данные чтобы определить что делать с пакетом. Особо подчеркну, что именно здесь должен вступать в игру обработчик правил фильтрации входящих пакетов брэндмауэра (о, блин, словечко ...) если таковой имеется. 5. Если после всех проверок система решает пропустить пакет, то IM использует ф-ю NdisMIndicateReceivePacket (здорово выглядит вызов минипортной ф-и из протокольного контекста ) указывая 1м аргументом хэндлер (незнаю как перевести) на контекст привязки вышерасположенного PD к виртуальному адаптеру IM, и таким образом, пакет уходит в PD. Путь исходящего пакета (с IM). 1. Сформировав пакет PD вызывает NdisSend/NdisSendPacket указывая контекст привязки к виртуальному адаптеру IM, как 1й аргумент. 2. Определив из контекста "куда дуть", NDIS вызывает зарегистрированный IM-ом колбэк MiniportSendPackets. 3. MiniportSendPackets проверяет и копирует пакет, проверяеи состояние MP (> D0), и запускает обработчик правил фильтрации исходящих пакетов брэндмауэра. 4. Если все вышеперечисленное прошло на ОК, то для данного пакета вызывается ф-я NdisSend с указанием на контекст привязки к реальному адаптеру низлежащего MP, и пакет уплывает дальше... Следует особо отметить, что в отличае от других систем NDIS_PACKET копируется при прохождении с уровня на уровень (а не передается через указатели, как например sk_buf в Linux). Aks.
|
|
|
Записан
|
|
|
|
new_s
|
|
« Ответ #127 : 24-04-2006 07:55 » |
|
а не могли бы вы объяснить(я думаю смый интересный вопрос) как распотрошить пакет?
Именно это.
|
|
|
Записан
|
|
|
|
mamont
Гость
|
|
« Ответ #128 : 25-04-2006 07:49 » |
|
Здравствуйте.. Я тоже пишу IM NDIS драйвер для диплома.. Драйвер должен шифровать исходящие (на определенный адрес) пакеты.. и расшифровывать входящие.. С шифрованием я пока не заморачивался.. пока пытаюсь сделать инкапсуляцию.. т.е. к исходящему пакету приконопатить новый заголовок.. а с входящего снимать.. так вот.. с исходящими пакетами все нормально.. заголовок добавляется (CommView показывает).. в MpSendPackets отправка реализована.. но как эти пакеты правильно принимать??? в PtRecievePacket написал.. не принимает.. такое впечатление, что просто рубит пакеты.. пробовал в PtRecieve.. тоже не получается.. Посоветуйте чего нибудь... Может у кого пример есть(работающий) с инкапсуляцией пакетов?
|
|
|
Записан
|
|
|
|
Uhri
Гость
|
|
« Ответ #129 : 26-04-2006 15:32 » |
|
Спасибо, Акс! Вроде понятне стало. Буду продолжать мучать. Да, кстати, ты там говорил о двух способах подклучения драйвера... и сказал, что интересует первый... так вот, меня скорее интересует как раз второй... В идеале хочу сделать что-то типа трафик-шейпера. Разделять канал хотя бы по клиентам (IP). Ведь насколько я понял из NDIS_PACKET определить IP проще, чем службу прикладного уровня, для которой этот пакет предназначен?
|
|
|
Записан
|
|
|
|
aks68
|
|
« Ответ #130 : 27-04-2006 14:11 » |
|
а не могли бы вы объяснить(я думаю смый интересный вопрос) как распотрошить пакет?
Именно это. Добрый день! Извлечение данных из обработанного Ethernet фрейма и из структуры NDIS_PACKETНа данном этапе я, увы, нераспалагаю достаточным к-вом времени, что-бы опробовать нижепреведенный метод на практике. Метод подсмотрен у ребят из ndis.com. У себя на работе я делаю в общем то-же самое, но немного подругому, однако рабочий код не могу привести по понятным соображениям . Я надеюсь, что все нижеприведенное поможет Вам, и буду очень рад если Вы сообщите о полученных результатах. Как уже было сказано ранее данные могут поступать в IM двумя путями - через колбэк зарегистрированный как ProtocolReceive, либо через колбэк зарегистрированный как ProtocolReceivePacket. В 1-м случае в ф-ю передаются указатели на части обработанного MP-ом Ethernet фрейма, а именно указатель на блок заголовка пакета и его длинна (HeaderBuffer и HeaderBufferSize) и указатель на кусок данных пакета - т.н. LookAhead Buffer - который можно использовать для экспресс-тестов (LookAheadBuffer и LookaheadBufferSize). Из HeaderBuffer легко извлекается тип пакета: PktType = HeaderBuffer[12] * 0x100U + HeaderBuffer[13]; Возможные варианты значения: 1. PktType < 0x05dc (IEEE 802.2/802.3 Encapsulation - RFC 1042) 2. PktType == 0x0800 IP (Ethernet Incapsulation - RFC 894) 3. PktType == 0x0806 ARP (Ethernet Incapsulation - RFC 894) 4. PktType == 0x8035 RARP (Ethernet Incapsulation - RFC 894) 5. PktType == 0x8137 IPX(Ethernet Incapsulation - RFC 894) Манипуляции по определению IP и портов могут производится над LookAheadBuffer-ом. Его длинна задается с помощю запроса к MP (NdisRequest) с указанием OID_GEN_CURRENT_LOOKAHEAD перед тем, как начинается прием пакетов. Предлагаемая техника : 1.Определяем структуры описывающие тот или иной заголовок (IP/TCP/UDP). 2. затем смещая указатель относительно начала блока (с учетом размера предыдущего заголовка) производим приведение типа данных 3. Получаем доступ к необходимым полям. Пример: /* Определяем структуру заголовка IP */ typedef struct _IP_HDR { UCHAR iph_verlen; UCHAR iph_tos; USHORT iph_length; USHORT iph_id; USHORT iph_offset; UCHAR iph_ttl; UCHAR iph_protocol; USHORT iph_xsum; ULONG iph_src; ULONG iph_dest; } IP_HDR, *PIP_HDR;
/* Вставка в ф-ю passthru зарегистрированную как ProtocolReceive */
NDIS_STATUS PtReceive( IN NDIS_HANDLE ProtocolBindingContext, IN NDIS_HANDLE MacReceiveContext, IN PVOID HeaderBuffer, IN UINT HeaderBufferSize, IN PVOID LookAheadBuffer, IN UINT LookAheadBufferSize, IN UINT PacketSize ) { ...
PIP_HDR pIpHdr; /* (1) */
...
pIpHdr = (PIP_HDR)LookAheadBuffer; /* (2) */
... /* (3) */ pIpHdr->iph_src; /* Source IP */ pIpHdr->iph_dest; /* Destination IP */
...
} Вторую часть по поводу извлечения данных из NDIS_PACKET я приведу позже. С уважением, Акс.
|
|
|
Записан
|
|
|
|
sss
Специалист
Offline
|
|
« Ответ #131 : 28-04-2006 07:52 » |
|
Вопрос. Как положить статью?
|
|
|
Записан
|
while (8==8)
|
|
|
new_s
|
|
« Ответ #132 : 01-05-2006 19:13 » |
|
Возник вопрос: А каких функции и какие возможности должен предоставлять firewall? Понятно что фильтровать трафик:) Я хотел бы услышать про коммерческую сторону. аск пример выше вроде не работает. компилятор ругается. (PktType имеет тип USHORT?)
|
|
« Последнее редактирование: 01-05-2006 20:48 от new_s »
|
Записан
|
|
|
|
Uhri
Гость
|
|
« Ответ #133 : 02-05-2006 09:30 » |
|
Есть 2 вопроса: 1. Как определить тип контента в NDIS_PACKET? Т.е. ftp или http и т.п.? 2. Как создавать потоки в passthru? в общем, хочу сделать так, чтобы драйвер определял тип данных и в зависимости от типа давал приоритет при передаче. Например, у http будет выше, чем, скажем у ftp. Алгоритм примерно такой в голове: 1) ловим пакет, 2) определяем тип контента, 3) вызываем функцию в отдельном патоке, которая будет с определенным интервалом времени отправлять пакеты (в зависимости от приоритета) Вот, кстати, тут еще один вопрос. Как насчет таймера в NDIS? Может кто рассказать что да как (желательно с примером). Что скажете по поводу задумки, товарищи программисты? Нормально или как всегда через ж?
|
|
|
Записан
|
|
|
|
aks68
|
|
« Ответ #134 : 04-05-2006 11:59 » |
|
Возник вопрос: А каких функции и какие возможности должен предоставлять firewall? Понятно что фильтровать трафик:) Я хотел бы услышать про коммерческую сторону. аск пример выше вроде не работает. компилятор ругается. (PktType имеет тип USHORT?)
Добрый день! Упс ... Да, надобно сделать приведение типов однако ... Давай так, я в ближайше 4 дня соберу на базе Пастру нечто, обрабатывающее пакеты приходящие на оба колбэка, и запосчу здесь. Так будет просче всего... Насчет возможностей firewall-а: 1. NAT 2. Анти спуффинг 3. Блокирование IP/портов/сервисов вообще 4. Блокирование всего из п3. для к-либо процесса (если fw бежит на end-point) 5. Опционально: взаимодействие с антивирусом (коли уж пакет получили) 6. Опционально: VPN 7. Опционально: потрошить данные на предмет всяких нехороших паттернов На просторах и-нета существует книга Building Internet Firewalls (O'Reilly), старенькая, но зато 100% есть в электронном виде. С уважением, Акс.
|
|
« Последнее редактирование: 14-12-2007 23:24 от Алексей1153++ »
|
Записан
|
|
|
|
heptohedron2004
Гость
|
|
« Ответ #135 : 05-05-2006 12:04 » |
|
Kife очень тебя прошу расскажи как сделать то, о чем ты говорил ранее (делаешь lib, компилишь в режиме ядра, прилинковываешь к драйверу), или хотя бы подскажи где енто можно прочитать а то извиняюсь вермя поджимает. Очень прошу откликнись хотя бы просто скажи что жив здоров и подскажи что нить.
|
|
|
Записан
|
|
|
|
Uhri
Гость
|
|
« Ответ #136 : 07-05-2006 11:20 » |
|
Ребятя! Нашел я заголовок TCP. Не пойму только на что именно указывает LookAheadBuffer. На начало всего пакета или же на пакет, начиная с IP заголовка (исключая Ethernet Header)? Вот сижу я щас тут гадаю... Есть хороший способ проверить, но не знаю как поользоваться... Скажите, как можно посмотреть содержимое той или иной переменной в процессе работы драйвера? Увидел такую функцию DBGPRINT(). Я так полагаю она должна выводить на экран. Вот только куда именно и как?
|
|
|
Записан
|
|
|
|
new_s
|
|
« Ответ #137 : 07-05-2006 13:06 » |
|
Ребятя! Нашел я заголовок TCP. Не пойму только на что именно указывает LookAheadBuffer. На начало всего пакета или же на пакет, начиная с IP заголовка (исключая Ethernet Header)? Вот сижу я щас тут гадаю... Есть хороший способ проверить, но не знаю как поользоваться... Скажите, как можно посмотреть содержимое той или иной переменной в процессе работы драйвера? Увидел такую функцию DBGPRINT(). Я так полагаю она должна выводить на экран. Вот только куда именно и как?
Искренни поздравляю!!!! DBGPRINT - не функция а макрос, функция DbgPrint если про passthru то этот макрос делает так чтобы сначала выводилось сообщение о том что выведенное сообщение относится к passthru. Просмотреть выведенное можно специальными утилитами. Например можно взять с www.sysinternals.com утилитку----DebugView. Открываешь её и смотришь. Синтаксис DbgPrint взят от printf(это написано в ddk). DbgPrint даёт возможность "контролировать" драйвер. А что ты нашёл можно подробнее?
|
|
« Последнее редактирование: 07-05-2006 13:10 от new_s »
|
Записан
|
|
|
|
Uhri
Гость
|
|
« Ответ #138 : 07-05-2006 15:18 » |
|
Вот определение заголовка TCP. Он идет сразу за заголовком IP. // Structure of a TCP packet header.
typedef struct _TCP_Header { USHORT tcp_src; // Source port. USHORT tcp_dest; // Destination port. int tcp_seq; // Sequence number. int tcp_ack; // Ack number. USHORT tcp_flags; // Flags and data offset. USHORT tcp_window; // Window offered. USHORT tcp_xsum; // Checksum. USHORT tcp_urgent; // Urgent pointer. } TCP_Header, * TCP_Header; Исходя из этого я определил структуру пакета, включая Ethernet заголовок, IP и TCP: typedef struct _IP_Packet { char DestMAC[6]; char SrcMAC[6]; USHORT Type; // 0x0800 => IP. UCHAR iph_verlen; // Version and length. UCHAR iph_tos; // Type of service. USHORT iph_length; // Total length of datagram. USHORT iph_id; // Identification. USHORT iph_offset; // Flags and fragment offset. UCHAR iph_ttl; // Time to live. UCHAR iph_protocol; // Protocol. USHORT iph_xsum; // Header checksum. UINT iph_src; // Source address. UINT iph_dest; // Destination address. USHORT tcp_port; // Source port. USHORT tcp_dest; // Destination port. int tcp_seq; // Sequence number. int tcp_ack; // Ack number. USHORT tcp_flags; // Flags and data offset. USHORT tcp_window; // Window offered. USHORT tcp_xsum; // Checksum. USHORT tcp_urgent; // Urgent pointer. } IP_Packet, * pIP_Packet;
правда, вот, не получается пока использовать... не знаю где взять указатель на весь пакет... поэтому и хочу знать какие значения принимают переменные в процессе работы.
|
|
|
Записан
|
|
|
|
heptohedron2004
Гость
|
|
« Ответ #139 : 10-05-2006 08:33 » |
|
Люди мот кто нает ответьте пожалуйста внятно на следующий вопрос. Пусть у нас есть IP пакет. Мы перехватываем его в IMDriver-e, в функции к примеру MPSend(), добавляем NDIS буфер(например 8 байт) к NDISструктуре пакета(вконец, то бишь в хвост). В этот буфер пусть мы записываем всякую лабуду(это неважно). Пусть еще в поле ДАННЫЕ апи-пакета мы емеем тисипи. Теперь вопрос. Надо ли расчитывать црц(хоть какое) и еси надо то как и куда его пихнуть. И еще вопрос, нормально ли пойдет пакет дальше в сетку, то есть пойдет ли он весь с добавленными 8-ю байтами ? В том смысле что необходимо ли где нить изменять длину пакета или все-таки NDIS все сделает за нас?
|
|
|
Записан
|
|
|
|
heptohedron2004
Гость
|
|
« Ответ #140 : 10-05-2006 08:38 » |
|
Блин.... забыл еще сказать. На принимающей стороне, когда мы принимаем пакет например в функции PtReceivePacket, мы обрубаем эти 8 байт, то есть удаляем последний сначала буфер в NDIS структуре пакета. Вопросы те же что и выше )
|
|
|
Записан
|
|
|
|
aks68
|
|
« Ответ #141 : 11-05-2006 12:55 » |
|
Добрый день! Что-то не получается у меня нормально поработать с Пастру - нет времени . Однако вот этот код у меня побежал. Вставляется в protocol.c:PtReceive. Демонстрирует доступ к структурам пакета (см. мой пост выше)... //-------Это вставляется сверху ----------------- // IP Header
typedef struct _IP_HDR { UCHAR iph_verlen; UCHAR iph_tos; USHORT iph_length; USHORT iph_id; USHORT iph_offset; UCHAR iph_ttl; UCHAR iph_protocol; USHORT iph_xsum; ULONG iph_src; ULONG iph_dest; } IP_HDR, *PIP_HDR;
// TCP Header typedef struct _TCP_HDR { USHORT tcp_src; USHORT tcp_dest; int tcp_seq; int tcp_ack; USHORT tcp_flags; USHORT tcp_window; USHORT tcp_xsum; USHORT tcp_urgent; }TCP_HDR, *PTCP_HDR;
//-------Это вставляется в PtReceive ----------------- USHORT PktType; PCHAR Buf = HeaderBuffer; PIP_HDR pIpHdr; PUCHAR pOctSrc, pOctDst; PTCP_HDR pTcpHdr; DBGPRINT(("==> PtReceive.\n"));
// Check the packet // PktType = ((USHORT) Buf[12]) * 0x100U + (USHORT) Buf[13];
switch(PktType) { case 0x0800: DBGPRINT(("Packet type IP 0x%x\n", PktType));
// Trying to check IP adderss... pIpHdr = (PIP_HDR)LookAheadBuffer; pOctSrc = (PUCHAR) &(pIpHdr->iph_src); pOctDst = (PUCHAR) &(pIpHdr->iph_dest); DBGPRINT(("Packet from %d.%d.%d.%d to %d.%d.%d.%d\n",\ *pOctSrc, *(pOctSrc+1), *(pOctSrc+2), *(pOctSrc+3),\ *pOctDst, *(pOctDst+1), *(pOctDst+2), *(pOctDst+3) ));
switch(pIpHdr->iph_protocol) { case 0x01: DBGPRINT(("ICMP: ...\n")); break; case 0x06: // Trying to check TCP related parameters pTcpHdr = (PTCP_HDR)((PUCHAR)LookAheadBuffer + sizeof(IP_HDR)); DBGPRINT(("TCP: from port %d to port %d\n", pTcpHdr->tcp_src, pTcpHdr->tcp_dest)); break;
case 0x11: DBGPRINT(("UDP: ...\n")); break; } break; case 0x0806: DBGPRINT(("Packet type ARP 0x%x\n", PktType)); break; } С уважением, Акс.
|
|
|
Записан
|
|
|
|
new_s
|
|
« Ответ #142 : 11-05-2006 14:53 » |
|
Не могу поверить. Это что на каждый пакет нужна своя структура(IP,ARP,...)? Дайте тогда ссылку на книжку в которой это будет описано.
|
|
|
Записан
|
|
|
|
aks68
|
|
« Ответ #143 : 13-05-2006 21:27 » |
|
Не могу поверить. Это что на каждый пакет нужна своя структура(IP,ARP,...)? Дайте тогда ссылку на книжку в которой это будет описано.
Не на пакет, а на заголовок. И кроме того никто Вас не заставляет обрабаывать данные с помощю структур. Хотите пользуйтеь смещениями отноительно базы или еще чем другим... Но главное, это понимть каково представление данных, с которым Вы собираетесь работать. Ведь это очевидно, что не стоит и пытаться искать TCP-шные поля в ARP пакете. К слову сказать эта самая вложенность пакета в пакет значительно упрощает дело: если программа видит, что пакет RARP например, то его обработка завершена, а вот если попался IP с инкапсуляцией - пройдемте на экзекуцию, пожалуйста... А из существующего многообразия Вас на первом этапе будут интересовать лишь ARP и RARP для уровня соединений, IP и инкапсулированные в него ICMP/IGMP (ну и может залететь SPX от Новелл, хотя это вряд-ли) для сетевого уровня, а на транспортном TCP/UDP. Прикладной уровень пока трогать ненадо,-если хотите его обсудить давайте заведем отдельный тред... Ну а "книжка" у нас одна, RFC (790, 791) называется, как-бы пошло это не звучало. Еще могу отрекомендовать Tcp/Ip Illustrsted (vol 1) Ричарда Стивенса. На русском языке она есть да и в осле наверное тоже. Описание IP пакета приведено например здесь http://www.networksorcery.com/enp/protocol/ip.htmНу и вокруг там посмотрите... Конкретные описания структур приведу завтра, как до работы только доберусь. С уважением, Акс.
|
|
|
Записан
|
|
|
|
Uhri
Гость
|
|
« Ответ #144 : 14-05-2006 08:26 » |
|
что-то со структурами у меня не то... тип протокола в IP заголовке определяет нормально, а вот в заголовке TCP порты почему-то левые какие-то показывает. И все не меньше 1000 !!!
|
|
|
Записан
|
|
|
|
aks68
|
|
« Ответ #145 : 14-05-2006 10:32 » |
|
что-то со структурами у меня не то... тип протокола в IP заголовке определяет нормально, а вот в заголовке TCP порты почему-то левые какие-то показывает. И все не меньше 1000 !!!
Да, разумеется... Я там напорол, когда вычислял смещение до TCP-заголовка, т.к. длинна IP-заголовка определяется не сайзоффом, а полем HeaderLength (4-7 биты в pIpHdr->iph_verlen). Как с ним работать разберитесь самостоятельно. С уважением, Акс. PS: Помните про остро и тупоконечников, когда работаете с байтами!
|
|
« Последнее редактирование: 14-05-2006 10:46 от aks68 »
|
Записан
|
|
|
|
aks68
|
|
« Ответ #146 : 14-05-2006 10:40 » |
|
В продолжении ответа new_s... Вот 2 структуры которые я когда-то нарыл на ndis.com. Они похоже это тоже где-то нарыли, так что копирайт непонятно чей struct { ushort Source; ushort Dest; ushort Length; ushort Checksum; }UDPHeader; struct { uchar ich_type; uchar ich_code; ushort ich_xsum; ulong ich_param; }ICMPHeader; С уважением, Акс.
|
|
|
Записан
|
|
|
|
Uhri
Гость
|
|
« Ответ #147 : 15-05-2006 06:57 » |
|
Да, разумеется... Я там напорол, когда вычислял смещение до TCP-заголовка, т.к. длинна IP-заголовка определяется не сайзоффом, а полем HeaderLength (4-7 биты в pIpHdr->iph_verlen). Как с ним работать разберитесь самостоятельно. PS: Помните про остро и тупоконечников, когда работаете с байтами!
Так дело в том, что у меня ни так, ни так не выходит. Т.е. пробовал я как отдельно 2 структуры создавать, так и 1 на весь заголовок: typedef struct _IP_Packet { UCHAR iph_verlen; // Version and length. UCHAR iph_tos; // Type of service. USHORT iph_length; // Total length of datagram. USHORT iph_id; // Identification. USHORT iph_offset; // Flags and fragment offset. UCHAR iph_ttl; // Time to live. UCHAR iph_protocol; // Protocol. USHORT iph_xsum; // Header checksum. UINT iph_src; // Source address. UINT iph_dest; // Destination address. USHORT tcp_src; // Source port. USHORT tcp_dest; // Destination port. int tcp_seq; // Sequence number. int tcp_ack; // Ack number. USHORT tcp_flags; // Flags and data offset. USHORT tcp_window; // Window offered. USHORT tcp_xsum; // Checksum. USHORT tcp_urgent; // Urgent pointer. } IP_Packet, * pIP_Packet; Проверяю, разумеется, что за протокол, если TCP, то использую эту структуру. Попробую конечно с полем длины заголовка, но я думал, что размер IP-заголовка постоянный, ведь во многих источниках читал о нем и везде одинаковые поля одинаковых размеров. з.ы.а, да, еще такой интересный момент. В заголовке TCP есть 2 поля - порт отправителья и порт получателя. Что-то я не до конца врублюсь, а разве можно послыть с одного порта,чтоб получили на другом(ну,если тока вручную пакеты не собирать)?
|
|
« Последнее редактирование: 15-05-2006 07:01 от Uhri »
|
Записан
|
|
|
|
aks68
|
|
« Ответ #148 : 15-05-2006 08:41 » |
|
|
|
« Последнее редактирование: 15-05-2006 08:51 от aks68 »
|
Записан
|
|
|
|
aks68
|
|
« Ответ #149 : 15-05-2006 08:50 » |
|
Добрый день Ури (я правильно странскрибировал?), В своем предположении относительно IP заголовка Вы неправы. Длинна его может изменяться от 20 до 60 байт, и определяется 4-мя старшим битам поля iph_verlen. Взять их можно так: 1. Определить union для поля iph_verlen 2. Доступиться через битовое поле typedef struct _IP_HDR { union { UCHAR verlen; struct { UCHAR len:4; UCHAR ver:4; }ip; }iph_verlen;
... ... ...
pTcpHdr = (PTCP_HDR)((PUCHAR)LookAheadBuffer + 4 * pIpHdr->iph_verlen.ip.len);
... ... ...
При этом pTcpHdr должен сдвинуться на 20 байт относительно начала LookAheadBuffer. Попробуйте это. Я его не запускал, но работать (IMHO) должно. С уважением, Акс.
|
|
|
Записан
|
|
|
|
|