Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: [1]   Вниз
  Печать  
Автор Тема: Вердикт выносит юзермод или ждем в NDIS-драйвере  (Прочитано 8982 раз)
0 Пользователей и 1 Гость смотрят эту тему.
Zarathustra2010
Гость
« : 15-01-2010 14:13 » 

Всем здравствуйте!

Товарищи, сам я в драйверах новичок и только начал заниматься, оттого хочу посоветоваться со знающими.
Пишу простой контент-фильтр, перехват решил производить через NDIS IM.

Вопрос:
На вход в драйвер льется трафик, судьбу содержимого каждого пакета решает юзермодное приложение.
Как лучше организовать их (драйвера и приложения) сотрудничество?
Стоит ли делать ожидание в драйвере или следует отдать пакет приложению, не передавая его дальше по цепочке, а завершить его, но приложение само при необходимости "даст ему ход"? Чувствутю, второй вариант гораздо лучше.
Может какие еще есть варианты, более корректные?


Заранее очень благодарен!
« Последнее редактирование: 15-01-2010 15:21 от Sel » Записан
Ochkarik
Модератор

ru
Online Online
Пол: Мужской

« Ответ #1 : 15-01-2010 14:42 » 

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

и второе... я не очень уверен, поскольку с NDIS мало сталкивался...
но вы уверены, что сможете обеспечить достаточную скорость обмена между приложением фильтром и драйвером? не будет ли больших тормозов для сетевого траффика в этом случае? ведь пакетов может быть достаточно много, каждый отправлять приложению, и ждать ответ - накладные расходы на синхронизацию. чем мельче объем пакетов - тем больше накладных расходов. (на вскидку - боюсь меньше 5-10мкс на синхронизацию у вас реализовать в лоб не получится, при самом лучшем раскладе. но это я немного с потолка цифру беру. это мои предположения)

PS пардон, мой ответ пока не совсем по теме, но мне кажется, что надо сначала разобраться именно с этим) кстати попробуйте на форуме поискать, может быть, кто-то уже задавал вопрос про синхронизацию и фильтрацию трафика через NDIS.

кстати, а обязательно ли алгоритм фильтрации держать в приложении? не проще ли его заложить в драйвере, а приложение, в таком случае, будет давать набор правил для фильтрации? я думал - обычно так и поступают?

PPS вынужден отбежать, но обязательно забегу позже)) либо завтра буду.
« Последнее редактирование: 15-01-2010 14:43 от Ochkarik » Записан

RTFM уже хоть раз наконец!  RTFM :[ ну или хотя бы STFW...
Zarathustra2010
Гость
« Ответ #2 : 15-01-2010 15:03 » 

1. Я как раз и спрашиваю, какой метод обычно используется. Два приведенных - все лишь предположения.
2. Конечно уверен, только метод подходящий найти нужно Ага
3. Боюсь, что алгоритм слишком для этого сложен, ведь речь идет не о правилах (!), а о контент-фильтре.
Записан
Ochkarik
Модератор

ru
Online Online
Пол: Мужской

« Ответ #3 : 15-01-2010 19:38 » 

по поводу "2"
    - я говорил о том что сложно добиться высокой скорости обмена с использованием KeSetEvent и WFSO между приложением и драйвером на пакетах малой длинны. там можно кое какие меры придумать, но они не всегда подойдут.

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

   в последнем случае(параметризация невозможна) - придется вызывать пользовательский код ring-3. этот подход - КРАЙНЯЯ МЕРА!!!! в большинстве случаев этот подход  ВСЕГДА и ЗНАЧИТЕЛЬНО повышает вероятность краха системы.  по дороге домой вспомнил - была тема на форуме по поводу вызова пользовательского кода из драйвера. если не ошибаюсь, тогда нашли возможность вызова кода пользовательского режима без расходов на синхронизацию.
   но! сильно не уверен что это допустимо для NDIS драйверов. для NDIS даже для выделения памяти - заведена Ndis-функция NdisAllocateMemoryWithTag().

да и вообще... если параметризация невозможна - тогда алгоритм построить.... что в приложении что в драйвере - одинаково..."сложно")

кстати, что подразумевается под "контент-фильтром"? и в чем несравнимая сложность реализации его в ring-0 по сравнению с  ring-3? единственная разница которую я знаю - невозможность использования расчетов на Floating-Point)))


PS я в большинстве случаев за то, чтобы все что возможно - перенести в драйвер)))) если его потом не требуется слишком часто переписывать - вещь получается красивая и "на века"))))
« Последнее редактирование: 15-01-2010 19:59 от Ochkarik » Записан

RTFM уже хоть раз наконец!  RTFM :[ ну или хотя бы STFW...
Zarathustra2010
Гость
« Ответ #4 : 18-01-2010 09:36 » 

Ochkarik,
Повторюсь, драйвер используется исключительно как поставщик данных, никакой логики по дата-контролю/-модификации в нем нет.
Просьба подсказать правильное решение в организации такого взаимодействия двух модулей.
Знаю что такое делается и работает достаточно быстро чтобы не делать из этого проблемы. Не знаю только как именно.

ЗЫ Например, есть у фирмы PCAUSA примеры NDIS- и TDI- драйверов работающие как раз по этой схеме. Но исходники этих драйверов стоят не малой суммы долларов, потому глянуть как они это дело сделали нет возможности. Но и все же хотелось бы посоветоваться, уверен, что таких путей существует больше одного.
Записан
Ochkarik
Модератор

ru
Online Online
Пол: Мужской

« Ответ #5 : 18-01-2010 12:57 » 

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

насчет синхронизации. если быстро то наверное всякие Event и APC не пойдет (хотя насчет APC не уверен)
вроде бы есть способы вызывать пользовательский код. вроде не так давно на форуме обсуждали - пол часа искал не нашел... потом еще пороюсь...
надо посмотреть
что то вроде https://forum.shelek.ru/index.php/topic,2683.0.html
вроде и вызов функций dll пытались сделать https://forum.shelek.ru/index.php/topic,8717.0.html

давно было большое обсуждение NDIS https://forum.shelek.ru/index.php/topic,7748.0.html

и надо посмотреть что есть в самих NDIS функциях для передачи и синхронизации.
Записан

RTFM уже хоть раз наконец!  RTFM :[ ну или хотя бы STFW...
Ochkarik
Модератор

ru
Online Online
Пол: Мужской

« Ответ #6 : 02-02-2010 21:19 » new

кстати... мысль случайно пришла. если есть готовые скомпилированные аналоги, то DependencyWalker покажет использованные функции)
может быть натолкнет на правильные мысли...
кстати на том сайте полно инфы...
например http://www.pcausa.com/filters/IPPacketRedirector.pdf
там показано что передача может  происходит через файл ReadFile/WriteFile.
второй вариант IP Packet Redirector - кажется они создают виртуальный порт? то есть читают из реального порта, и записывают в виртуальный который предоставляется системе.
по моему там широкое поле для размышлений даже исходя из информации на сайте)
« Последнее редактирование: 02-02-2010 21:24 от Ochkarik » Записан

RTFM уже хоть раз наконец!  RTFM :[ ну или хотя бы STFW...
Страниц: [1]   Вверх
  Печать  
 

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines