NDIS InterMediate Driver - Обсуждение

[brovy@n]

Да уже допетрил........ Спасиб 
 ----------------------

Просто ради интересу: где сервак находится, на котором этот сайтец хостица?
а то у меня ужо 3:57, только a.m. и уже 23 число!!!(типа пасха)

[brovy@n]

P.S. На Солдатова только что наткнулся

[Finch]

Просто ради интересу: где сервак находится, на котором этот сайтец хостица?
а то у меня ужо 3:57, только a.m. и уже 23 число!!!(типа пасха)

Хотя это оффтоп. Но Сервер стоит в Москве и время Сервера -2 часа GMT. Чтобы у тебя показывалось нормальное время, ты должен сам в своих настройках профиля настроить временное смешение. Секция называется "Внешний вид форума". Пункт "Time Offset".

[aks68]

Спасибо за совет.
Насчет 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]

а не могли бы вы объяснить(я думаю смый интересный вопрос) как распотрошить пакет?

[aks68]

а не могли бы вы объяснить(я думаю смый интересный вопрос) как распотрошить пакет?

Добрый день!

В начале я хотел-бы закончить с примерами прохождения пакета, раз уж начал...
Хотя непредставляю, что там из пакета такого можно "выпотрашить"?
Ну тип пакета, IP-адреса, TCP-порты... что-то еще?

С уважением,
Акс.

[aks68]

Продолжение про пакеты...

Существуют 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]

а не могли бы вы объяснить(я думаю смый интересный вопрос) как распотрошить пакет?

Именно это.

[mamont]

Здравствуйте..
Я тоже пишу IM NDIS драйвер для диплома..
Драйвер должен шифровать исходящие (на определенный адрес) пакеты.. и расшифровывать входящие..
С шифрованием я пока не заморачивался..
пока пытаюсь сделать инкапсуляцию.. т.е. к исходящему пакету приконопатить новый заголовок..
а с входящего снимать..
так вот..
с исходящими пакетами все нормально.. заголовок добавляется (CommView показывает)..
в MpSendPackets отправка реализована..
но как эти пакеты правильно принимать???
в PtRecievePacket написал.. не принимает.. такое впечатление, что просто рубит пакеты..
пробовал в PtRecieve.. тоже не получается..
Посоветуйте чего нибудь...
Может у кого пример есть(работающий) с инкапсуляцией пакетов?

[Uhri]

Спасибо, Акс! Вроде понятне стало. Буду продолжать мучать.
Да, кстати, ты там говорил о двух способах подклучения драйвера... и сказал, что интересует первый... так вот, меня скорее интересует как раз второй... В идеале хочу сделать что-то типа трафик-шейпера. Разделять канал хотя бы по клиентам (IP). Ведь насколько я понял из NDIS_PACKET определить IP проще, чем службу прикладного уровня, для которой этот пакет предназначен?

[aks68]

а не могли бы вы объяснить(я думаю смый интересный вопрос) как распотрошить пакет?

Именно это.

Добрый день!

Извлечение данных из обработанного 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]

Вопрос. Как положить статью?

[new_s]

Возник вопрос:
А каких функции и какие возможности должен предоставлять firewall?
Понятно что фильтровать трафик:)
Я хотел бы услышать про коммерческую сторону.
аск пример выше вроде не работает.
компилятор ругается.
(PktType имеет тип USHORT?)

[Uhri]

Есть 2 вопроса:
1. Как определить тип контента в NDIS_PACKET? Т.е. ftp или http и т.п.?
2. Как создавать потоки в passthru?
в общем, хочу сделать так, чтобы драйвер определял тип данных и в зависимости от типа давал приоритет при передаче. Например, у http будет выше, чем, скажем у ftp.
Алгоритм примерно такой в голове:
1) ловим пакет,
2) определяем тип контента,
3) вызываем функцию в отдельном патоке, которая будет с определенным интервалом времени отправлять пакеты (в зависимости от приоритета)
Вот, кстати, тут еще один вопрос. Как насчет таймера в NDIS? Может кто рассказать что да как (желательно с примером).
Что скажете по поводу задумки, товарищи программисты? Нормально или как всегда через ж?

[aks68]

Возник вопрос:
А каких функции и какие возможности должен предоставлять 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% есть в электронном виде.

С уважением,
Акс.

[heptohedron2004]

Kife очень тебя прошу расскажи как сделать то, о чем ты говорил ранее (делаешь lib, компилишь в режиме ядра, прилинковываешь к драйверу), или хотя бы подскажи где енто можно прочитать а то извиняюсь вермя поджимает. Очень прошу откликнись хотя бы просто скажи что жив здоров и подскажи что нить.

[Uhri]

Ребятя! Нашел я заголовок TCP. Не пойму только на что именно указывает LookAheadBuffer. На начало всего пакета или же на пакет, начиная с IP заголовка (исключая Ethernet Header)?
Вот сижу я щас тут гадаю... Есть хороший способ проверить, но не знаю как поользоваться... Скажите, как можно посмотреть содержимое той или иной переменной в процессе работы драйвера? Увидел такую функцию DBGPRINT(). Я так полагаю она должна выводить на экран. Вот только куда именно и как?

[new_s]

Ребятя! Нашел я заголовок TCP. Не пойму только на что именно указывает LookAheadBuffer. На начало всего пакета или же на пакет, начиная с IP заголовка (исключая Ethernet Header)?
Вот сижу я щас тут гадаю... Есть хороший способ проверить, но не знаю как поользоваться... Скажите, как можно посмотреть содержимое той или иной переменной в процессе работы драйвера? Увидел такую функцию DBGPRINT(). Я так полагаю она должна выводить на экран. Вот только куда именно и как?

Искренни поздравляю!!!!
DBGPRINT - не функция а макрос, функция DbgPrint если про passthru то этот макрос делает так чтобы сначала выводилось сообщение о том что выведенное сообщение относится к passthru.
Просмотреть выведенное можно специальными утилитами.
Например можно взять с www.sysinternals.com утилитку----DebugView.
Открываешь её и смотришь.
Синтаксис DbgPrint взят от printf(это написано в ddk).
DbgPrint даёт возможность "контролировать" драйвер.
А что ты нашёл можно подробнее?

[Uhri]

Вот определение заголовка 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]

Люди мот кто нает ответьте пожалуйста внятно на следующий вопрос.
Пусть у нас есть IP пакет. Мы перехватываем его в IMDriver-e, в функции к примеру MPSend(), добавляем NDIS буфер(например 8 байт) к NDISструктуре пакета(вконец, то бишь в хвост). В этот буфер пусть мы записываем всякую лабуду(это неважно). Пусть еще в поле ДАННЫЕ апи-пакета мы емеем тисипи. Теперь вопрос. Надо ли расчитывать црц(хоть какое) и еси надо то как и куда его пихнуть. И еще вопрос, нормально ли пойдет пакет дальше в сетку, то есть пойдет ли он весь с добавленными 8-ю байтами ? В том смысле что необходимо ли где нить изменять длину пакета или все-таки NDIS все сделает за нас?

[heptohedron2004]

Блин.... забыл еще сказать. На принимающей стороне, когда мы принимаем пакет например в функции PtReceivePacket, мы обрубаем эти 8 байт, то есть удаляем последний сначала буфер в NDIS структуре пакета. Вопросы те же что и выше )

[aks68]

Добрый день!

Что-то не получается у меня нормально поработать с Пастру - нет времени .
Однако вот этот код у меня побежал. Вставляется в 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]

Не могу поверить.
Это что на каждый пакет нужна своя структура(IP,ARP,...)?
Дайте тогда ссылку на книжку в которой это  будет описано.

[aks68]

Не могу поверить.
Это что на каждый пакет нужна своя структура(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]

что-то со структурами у меня не то... тип протокола в IP заголовке определяет нормально, а вот в заголовке TCP порты почему-то левые какие-то показывает. И все не меньше 1000 !!!

[aks68]

что-то со структурами у меня не то... тип протокола в IP заголовке определяет нормально, а вот в заголовке TCP порты почему-то левые какие-то показывает. И все не меньше 1000 !!!

Да, разумеется...
Я там напорол, когда вычислял смещение до TCP-заголовка, т.к. длинна IP-заголовка определяется не сайзоффом, а полем HeaderLength (4-7 биты в pIpHdr->iph_verlen). Как с ним работать разберитесь самостоятельно.

С уважением,
Акс.

PS: Помните про остро и тупоконечников, когда работаете с байтами!

[aks68]

В продолжении ответа 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]

Да, разумеется...
Я там напорол, когда вычислял смещение до 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 поля - порт отправителья и порт получателя. Что-то я не до конца врублюсь, а разве можно послыть с одного порта,чтоб получили на другом(ну,если тока вручную пакеты не собирать)?

[aks68]

  ОЧИПЯТКА 

[aks68]

Добрый день Ури (я правильно странскрибировал?),

В своем предположении относительно 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) должно.

С уважением,
Акс.