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

[new_s]

Можно написать про извлечение информации из пакета?
И про то какие функции нужно регистрировать и обрабатывать в driverentry

[BlackStar]

Да чё, собственно, изобретать велосипед! На второй странице темы есть список минимально необходимых вопросов по NDIS. Вот их и освещать. И, если это дело довести до конца, то бОльшая часть криков о помощи будет удовлетворена. А потом уже можно и за более хитрые проблемы браться.

[zim]

Скорее ветка уже давно погибла, но я все же рискну. Вопрос касается IM NDIS драйвера. Предположим, что в ProtocolReceive из NDIS-пакета мы получили Ethernet-пакет. Также существует функция, назовем ее Read, вызываемая при обращении пользователя к устройству драйвера с    запросом на чтение данных (в DriverEntry: MajorFunctions[IRP_MJ_READ] = Read). Вопрос: как передать полученный пакет в ProtocolReceive в функцию Read, так чтобы этот пакет добрался до пользователя. Пожалуйста помогите, через пару дней сдавать диплом , спасибо

[resource]

В ProtocolReceive ставь пакет в очередь, а в обработчике IRP_MJ_READ читай. Какие проблемы то?

[zim]

Извините за глупые вопросы, но в какую очередь и как передать пакет из ProtocolReceive в обработчик IRP_MJ_READ ?

[resource]

Думаю за пару дней вам никак не успеть.

[zim]

Хотя бы дайте направление где копать...

[resource]

Что такое очередь и как ее реализовать - это уже не по драйверам вопрос. Вам лучше задать его в другом разделе.

[zim]

Что такое очередь я знаю, просто я думал что в NDIS уже что-то вроде очереди реализовано, вопрос не в этом. Как синхронизировать передачу данных?, правильно ли будет использовать полученный пакет как глобальную переменную?, может использовать спин-блокировки?  Просто хотелось бы получить совет как все это лучше и правильней организовать...

[sss]

Блин, вернулся в тему... Вот незадача - не могу установить привязку фильтра к минипорту WAN? кто-нибудь знает как это сделать?
Вот такие вещи в inf  не прокатывают - привязки нет...

Код:

  HKR, Ndi\Interfaces, FilterMediaTypes,    , "ethernet, tokenring, fddi, ndiswan, isdn, wan"

Подозреваю надо писать WAN минипорт... Может кто куда нибудь пошлет... Почитать..

[sss]

в общем так...
Помимо исправлений в inf, стал смотреть - что возвращает NdisIMInitializeDeviceInstanceEx в PtBindAdapter.
Возвращает  NDIS_STATUS_UNSUPPORTED_MEDIA (0xC0010019L). Зырю дальше - там в вызове используется хэндл, полученный
вызовом NdisOpenAdapter, в котором в качестве параметра передается MediumArray, равный в стандартном passthru

Код:

NDIS_MEDIUM  MediumArray[3] =
{
   NdisMedium802_3, // Ethernet
   NdisMedium802_5, // Token-ring
   NdisMediumFddi   // Fddi
};

Ну ладно, думаю, добавлю NdisMediumWan - OK! Вернулся статус NDIS_STATUS_SUCCESS..
Ну все, думаю заживу теперь как надо - ни хера.. Даже если учесть, что я не знаю что
передавать в функцию NdisMWanIndicateReceive, у меня случился синяк где то в недрах
сразу после выхода из функции ProtocolStatus

Код:

STACK_TEXT: 
b4abee90 8053658b 00000003 b4abf1ec 00000000 nt!RtlpBreakWithStatusInstruction
b4abeedc 8053705e 00000003 00000000 b4abf6c0 nt!KiBugCheckDebugBreak+0x19
b4abf2bc 80537672 0000008e c0000005 00000000 nt!KeBugCheck2+0x574
b4abf2dc 805221e9 0000008e c0000005 00000000 nt!KeBugCheckEx+0x1b
b4abf6a4 804de3f3 b4abf6c0 00000000 b4abf714 nt!KiDispatchException+0x3b1
b4abf70c 804de3a4 b4abf7c0 00000000 badb0d00 nt!CommonDispatchException+0x4d
b4abf784 b7373f31 89703ad0 89264d08 89772ad0 nt!Kei386EoiHelper+0x18a
b4abf7c0 f743c434 895eb008 89264d08 00000082 psched!MpSend+0x10f
b4abf7f4 b8765404 897b0118 00000000 00000001 NDIS!ndisMSendPacketsX+0x1d5
b4abf810 b8765707 8974c008 895621d0 895c8228 wanarp!WanpSendPackets+0xfc
b4abf854 b509badc 8974c008 b4abf944 00000001 wanarp!WanIpTransmit+0x14f
b4abf990 b5082305 b50b9b34 89056e40 89014020 tcpip!IPTransmit+0x723
b4abfa30 b50820cc 88c2ee98 89056e40 88fd0008 tcpip!UDPSend+0x41b
b4abfa54 b5082132 00abfa78 88fd0180 89014060 tcpip!TdiSendDatagram+0xd5
b4abfa8c b507e881 88fd0008 88fd00c0 88fd0180 tcpip!UDPSendDatagram+0x4f
b4abfaa8 804e13c9 89800030 88fd0008 890b9790 tcpip!TCPDispatchInternalDeviceControl+0xff
b4abfab8 b5039707 b4abfba8 00000008 b4abfb1c nt!IopfCallDriver+0x31
896ec030 8979c030 00000012 b5078000 00058380 afd!AfdFastDatagramSend+0x2fd

Ёлки, где почитать про работу с WAN??

[Ochkarik]

пардон что поздно но...
Overview of the WAN Architecture (NDIS 5.1)
WAN Miniport Drivers (NDIS 5.1)
Registering an NDIS WAN Miniport Driver (NDIS 5.1)

[sss]

Мда... Спасибо Ochkarik... Я думал обойтись малой кровью.

[Ochkarik]

ну.... насчет обойтись - я просто не знаю... сети - совсем не моя тематика)

[supermaxus]

Копаюсь сейчас в этой теме по реальной задаче. Хочу опубликовать свои изыски, возможно, кому-то будет интересно.

Общественности широко известны два пути получения данных intermediate драйвером из нижележащего драйвера (сетевой карты ethernet):
- драйвер сетевой карты вызывает NdisMCoIndicateReceivePacket, что приводит к вызову модной ныне функции ProtocolReceivePacket intermediate драйвера, если она определена.
- драйвер сетевой карты вызывает NdisMCoIndicateReceivePacket, что приводит к вызову в ProtocolReceive intermediate драйвера, если ProtocolReceivePacket  не определена.

Помимо этих двух путей есть третий. С этим путем связана проблема получения null при вызове функции NdisGetReceivedPacket (которая должна бы вернуть хендл на получаемый пакет) в семпле passthru. Если ваш драйвер не обращает внимания на этот путь, то на некоторых (видимо, особо старых) сетевых картах пакеты пойдут в вышележащие драйвера без ведома вашего intermediate драйвера. В моем случае ситуация обнаружилась на 1 компе из 3-х тестируемых.

Идея в следующем:
- драйвер сетевой карты вызовом NdisMXxxIndicateReceive сообщает, что пришло нечто размером меньше пакета. Сама ситуация мне кажется абсурдной, поскольку пакет формирует именно драйвер сетевой карты (он получил меньше ethernet фрейма, чтоль? Видимо, скорее всего, тогда пакета еще в природе не было.. но я те времена не застал:). В DDK про это  в разделе "Indicating Receives with an NdisMXxxIndicateReceive Function" сказано так: "The miniport driver indicates up a partial packet, or possibly the complete packet if it is small enough". Поверим DDK на слово:) Т.е. возможность приема части пакета принципиально допускается. Указанной функцией "NDIS forwards the indication to all interested protocols"(извещает все привязанные вышележащие протоколы о получении части пакета).
- Далее обращаем внимание на: "If it is a partial packet and a protocol is interested in the complete packet, the protocol calls NdisTransferData to request the remaining net packet data". Т.е. вышележащий протокол вызывает NdisTransferData для получения остатка данных в пакете, что приводит к вызову функции нашего драйвера MiniportTransferData (поскольку именно наш минипорт экспортируется в вышележащие драйверы). Наша функция вызывает NdisTransferData применительно к драйверу сетевой карты и тем самым транслирует данные в вышележащий драйвер минуя наши функции ProtocolReceive и ProtocolReceivePacket, которые в данном случае не вызываются (вызов ProtocolReceive с пустым пакетом - за толковый вызов не считается).

Если посмотреть на это безобразие с другой стороны, то можно сказать, что с начала времен в NT, видимо, драйвера использовали pull технологию (я сигналю, а берите - кому надо [MiniportTransferData]). Со временем, концепция подачи информации изменилась на push (я сигналю, а вы обязаны брать[ProtocolReceivePacket, ProtocolReceive]). Тем не менее, сейчас все еще встречаются сетевые карты со старыми дровами, которые используют pull технологию.

Теперь резюмирую: в intermediate драйвере надо не только учитывать pull технологию, но и потрошить пакеты для pull и push технологии, видимо, надо тоже по-разному. Иначе ваш файервол будет ситом на радость хацкерам:)



Добавлено через 4 минуты и 59 секунд:
Не допечаталось..
Со временем, концепция подачи информации изменилась на push (я сигналю, а вы обязаны брать[ProtocolReceivePacket, ProtocolReceive]). Тем не менее, сейчас все еще встречаются сетевые карты со старыми дровами, которые используют pull технологию.

Теперь резюмирую: в intermediate драйвере надо не только учитывать pull технологию, но и потрошить пакеты для pull и push технологии, видимо, надо тоже по-разному. Иначе ваш файервол будет ситом на радость хацкерам:)


Добавлено через 1 минуту и 44 секунды:
ох, е.. дубль 3

Со временем, концепция подачи информации изменилась на push (я сигналю, а вы обязаны брать/ProtocolReceivePacket, ProtocolReceive/). Тем не менее, сейчас все еще встречаются сетевые карты со старыми дровами, которые используют pull технологию.

Теперь резюмирую: в intermediate драйвере надо не только учитывать pull технологию, но и потрошить пакеты для pull и push технологии, видимо, надо тоже по-разному. Иначе ваш файервол будет ситом на радость хацкерам:)


Все допечаталось. Но движку почему-то не нравится конструкция "[ProtocolReceivePacket, ProtocolReceive]" и при выдаче он по ней обрезает пост. При редактировании и предпросмотре все нормально. Я обернул их тегами [ nobbc ].

[supermaxus]

Спасибо.

Еще интересная информация. В связи с тем, что заставить сетевые карты с новыми драйверами работать 3 способом  путем отключения ProtocolReceivePacket не получилось (все-равно принимает все в пакетном режиме), у разработчиков возникнет проблема проверки написанного кода для этого случая. Мне удалось найти еще одну машину, где пакеты принимаются сходным образом. Версия драйвера сетевой карты на обеих машинах датируется 2002 годом, хотя дрова от 2003 года уже работают в пакетном режиме. Т.о. ищите сетевую карту с дровами от 2002 года. Пример готовой функции(NdisProtReceive) есть в семпле ndisprot из ddk.

[yol]

В форуме обсуждалась возможность модификации драйвера passthru для перехвата пакетов от модема (конкретно интересует gsm-модем). Passthru никак не хочет привязываться к модему и инициализировать его минипорт. Интересно, у кого-нть это получилось?

[supermaxus]

А Вы уверены, что gsm момед работает именно через сетевой стек? Насколько я помню, все мобильники (которые имеют встроенный gsm модем) работают через com-порты, что не имеет никакого отношения к сетевому стеку и Passthru в частности.

PS видимо, там где было обсуждение, речь шла об adsl-модеме, который подсоединяется через ethernet, а это - совсем другая история

[Ochkarik]

supermaxus,  действительно) но помоему был и обычный... но там делать надо)
yol, что значит не хочет? как подключали, чего пишет, какие симптомы, какие статусы? и что за модем наконец?)

[yol]

У меня USB-брелок GSM модем. Включаю его в комп.
С устройством работают два драйвера: modem.sys и qcusebser.sys. Смотрю утилитой OidScope
от PCAUSA: модем после установки соединения появляется как "RAS асинхронный адаптер" в
списке сетевых карт, пишет, что medium = WAN. Иду в Сетевые подключения и в свойствах
соединения "ModemInterface" во вкладке "Сеть" (там PPP interface) ставлю драйвер passthru
как службу. Драйвер ставится. Поэтому, мне кажется, что он вполне себе через сетевой стек работает.
Только хотелось бы знать, как именно.
Потом хочу увидеть дебагпринты из passthru, их нет.
Для обычной сетевухи на том же компе passthru дебагпринты говорят, что все ок:
bindadapter, miniport initialize, register device.

Добавлено через 6 минут и 18 секунд:
модем Alcatel, HSPA USB modem

Добавлено через 1 минуту и 36 секунд:
хотелось бы с помощью IM драйвер перехватывать и модифицировать пакеты

[supermaxus]

ИМХО, USB-устройство никогда через сетевой стек данные не гоняет(как-бы смысла нет), поскольку оно сразу видится как com-порт, а для них есть отдельная группа драйверов (становятся рядом с сетевыми и не взаимодействуют с последними).

ИМХО, "RAS асинхронный адаптер" тож на это указывает - он прямо на COM и работает. Если б устройство ходило через ethernet, то называлось бы оно как-то так:  Alcatel, HSPA ethernet modem

PS но посмотрев на фотографию устройства я ума не приложу куда там воткнуть RJ-45 розетку

PPS не поленился посмотреть ddk в контексте ras. Вылезла занятная схемка, которая показывает, что ras работает с драйвером Ndiswan.sys, или ниже. Т.о.  если и идет что-то через сетевой стек, то свой intermediate надо втыкать ниже Ndiswan.sys (ближе к WAN miniport driver). Интересно, хто-нить такое делал?


Добавлено через 2 минуты и 57 секунд:

supermaxus,  действительно) но помоему был и обычный... но там делать надо)
...

Нда.
ИМХО, там работа ради работы - быстрее ведь все равно работать не будет..

[yol]

ИМХО, USB-устройство никогда через сетевой стек данные не гоняет(как-бы смысла нет), поскольку оно сразу видится как com-порт, а для них есть отдельная группа драйверов (становятся рядом с сетевыми и не взаимодействуют с последними).

Например, YOTA USB modem ("Samsung USB mWiMAX Adapter", драйвер C76xUSB76.sys) или wifi USB модем
("USB-адаптер беспроводных сетей 802.11n USB Wireless LAN", драйвера netr28ux.sys,
vwifibus.sys) тоже USB-устройства (с YOTA даже съемный диск появляется), а определяются как сетевые карты и NDIS IM драйвер с ними отлично работает

[supermaxus]

Ну дык там прямо написано, что это Wimax, либо заявлена поддержка 802.11n. А у вас - просто HPSA, что, ИМХО, не имеет отношение к 802.xxx.

Если найти определение cтандарта IEEE 802.16 (wimax), то там будет указано примерно следующее: "Разработанный Институтом инженеров по электротехнике и электронике (IEEE) стандарт 802.16 представляет собой рассчитанную на внедрение в городских беспроводных сетях технологию, задачей которого является обеспечения сетевого уровня между локальными сетями (IEEE 802.11) и региональными сетями (WAN)".

http://www.softco.ru/80216.htm

Здесь очевидно, что драйвер работает с одной стороны с 802.11 - это обычный lan (и сетевой стек в терминах драйверов), и 802.16 - с другой, это wan (оборудование). Полагаю, здесь никакого ras не предвидится.

Определение HPSA из вики:
"HSPA (англ. High Speed Packet Access — высокоскоростная пакетная передача данных) — технология беспроводной широкополосной радиосвязи, использующая пакетную передачу данных и являющаяся надстройкой к мобильным сетям WCDMA/UMTS"

http://ru.wikipedia.org/wiki/High_Speed_Packet_Access

А здесь речи о взаимодействии с  локальными сетями (IEEE 802.11) - нет. И работает оно, видимо, через ras, т.о. пакеты выше Ndiswan.sys в сетевом стеке не поднимаются. И если что-то и можно поймать, то только когда воткнете passthru ниже Ndiswan.sys (если получится), о чем указывал в pps.

Все ИМХО.

ps

определяются как сетевые карты

Собсно, я об этом же - как сетевые карты, а не как ras в вашем случае.

[yol]

А здесь речи о взаимодействии с  локальными сетями (IEEE 802.11) - нет. И работает оно, видимо, через ras, т.о. пакеты выше Ndiswan.sys в сетевом стеке не поднимаются. И если что-то и можно поймать, то только когда воткнете passthru ниже Ndiswan.sys (если получится), о чем указывал в pps.

Даа, ниже Ndiswan.sys - это очень низкий уровень. Наверное, проще копать в сторону com/usb-порта, встроиться в тот стек как фильтр, если получится, для перехвата и модификации пакетов..

[supermaxus]

Попробуйте изменить настройки inf файлов passthru. Если получится загнать драйвер в нужное место, то, возможно, сможете получить ценную информацию и пополнить ею этот раздел

Сам Ndiswan.sys заявлен как intermediate драйвер. Но даже Билл Гейтц не знает чего и как оно там вызывает. Поэтому, некая вероятность получить ndis пакет все же есть.

[Antonim]

Приветствую, читающих.

Вопрос такой:
Хочу написать проксификатор/соксификатор под седьмые окна.
Сломал глаза, изнасиловал мозг в поиске адекватного(по уровню реализации) пути решения данной задачи.

Имею общее(и чуть больше) представление по WFP, LSP, TDI, NDIS решениях. О первых трех информация крайне противоположна(в плане работоспособности/быстродействия/рациональности реализации).

Так подскажите, пожалуйста, в какую степь-то идти?!

Заранее спасибо!

[resource]

Скажу простым языком о том, что юзал сам.

WFP, как можно понять из названия, предназначено в первую очередь для фильтрации трафика. Так же допускает возможность модификации содержимого пакетов. Это то, что нужно любому брандмуэру. Сниферы тоже его юзают.

WSK. Если вы знаете, что такое классические сетевые сокеты (или BSD сокеты), то WSK это тоже самое, только в ядре. Для фильтрации не используется.

NDIS это самый нижний уровень на виндовом "сетевом стэке". Помимо драйверов сетевых карт, на этом уровне живут модули серьезных брандмауэров, страхующие "верхний" рубеж защиты. Здесь тоже живут сниферы. NDIS это самый недружелюбный сетевой интерфейс, потому что здесь всё нужно делать руками и исключительно через зад. Здесь много вызовов на DISPATCH_LEVEL и как следствие, расходуется неподкачиваемая память, а также недоступна основная масса примитивов синхронизации (есть конечно аналоги, но с другими требованиями и ацким расходом памяти).

TDI ? Вроде как было сказано про Win7. TDI это орудие древнего человека, про него надо забыть. Нынче WFP + WSK это и есть TDI, только более удобные и логичные.

Вообще это уже отдельный топик получился, т.к к "NDIS InterMediate Driver" вопрос и, соответственно ответ, отношения не имеют.