Здравствуйте, TarasCo, Вы писали:
TC>Здравствуйте, DimanKGKZ, Вы писали:
DKG>>:)Подскажите пожалуйста, как реализовать можно. Думаю пипец большой не будет, ну хотябы потому, DKG>>что задержка будет не большая... я так думаю :), судя по dbgviewr-у. Даже если и будет тормозить, DKG>>так ему и надо. Это будет у компа основная обязанность.
TC>Можете попробывать так: TC>1. В обработчике который потенциально может находиться на DISPATCH_LEVEL, но должен ждать код на PASSIVE_LEVEL запретить прерывания: TC>__asm cli TC>2. Крутиться в цикле, проверяя некий флаг TC>3. Флаг проверять с помощью InterlockedCompareExchange TC>4. После установки флага разрешить прерывания и продолжить выполнение.
TC>В потоке, который будет делать вспомогательные действия после их выполнения установить флаг с помощью любой Interlocked функции.
Тут еще нужно учесть, что поток на втором процессоре, выполняющий вспомогательные действия и исполняющийся на PASSIVE_LEVEL, может быть прерван для обработки того же самого (аналогичного тому которое висит на первом процессоре) сетевого события на DISPATCH_LEVEL. Тогда оба процессора будут ждать установки одного и того же флага.
Здравствуйте, Sergey Storozhevykh, Вы писали:
SS>Тут еще нужно учесть, что поток на втором процессоре, выполняющий вспомогательные действия и исполняющийся на PASSIVE_LEVEL, может быть прерван для обработки того же самого (аналогичного тому которое висит на первом процессоре) сетевого события на DISPATCH_LEVEL. Тогда оба процессора будут ждать установки одного и того же флага.
Чисто формально — конечно ( я кстати отметил, что возможно возникновение дедлоков ), но реально, в данной ситуации врядли. Дело в том, что обработка сетевого события на DISPATCH_LEVEL, а точнее сказать в DPC ( ведь именно постановка DPC в очередь может прервать выполнение потока ) возможна только при приеме сетевого пакета — отправка пакета происходит в контексте потока, нет нужды для этого ставить в очередь DPC. NDIS 5.0 устроена так, что на многопроцессорной машине только один процессор может обрабатывать DPC ( в отличие от NDIS 6.0 где основная фича — это RSS http://www.microsoft.com/whdc/device/network/NDIS_RSS.mspx ). Таким образом, в NT 5.0 врядли возможна такая ситуация. Но возможности для deallock ов повторю — остаются. Например, перед вызовом функции может быть захвачен какой-нибудь объект синхронизации, что тоже дает почву для дедлоков . Да и сама идея абсурдна — заставить ждать код на DISPATCH_LEVEL.
Здравствуйте, TarasCo, Вы писали:
TC>Чисто формально — конечно ( я кстати отметил, что возможно возникновение дедлоков ), но реально, в данной ситуации врядли.
Александр совершенно прав, причем меня это всегда настолько возмущало, что даже и в этом случае выкажусь — NDIS до шестерки был вообще на мой взгляд даже не многопоточным!... Библиотека имеет такую идиотскую архитектуру, что слов нет. Представьте несколько глобальных локов на глобальные списки которые при обращении к ней попросту блокируют вызвавшего и он висит на ожидании пока NDIS не освободится... А в части библиотеки для минипортов так вообще хачат по черному! — Вот всё хочу посмотреть как "это" сделано в висте.
...
TC>Да и сама идея абсурдна — заставить ждать код на DISPATCH_LEVEL.
Здравствуйте, onyx2, Вы писали:
O>2. Но по плохому подойдет и посылка IRP (IOCTL_TCP_QUERY_INFORMATION_EX) к \Device\Tcp (TarasCo говорил). Получите таблицу tcp соединений. Осуществите поиск в таблице на предмет наличия требуемого адреса и порта (т.е. тот адрес и порт, котрые пришли в пакете) в таблице tcp. Если найдете, то pid тоже известен из табл. tcp. Ну а если pid, известен, то это дело легко можно связать со списком процессов который вы создаете с помощью PsSetCreateProcessNotifyRoutine.
Если использовать IoCallDriver, то возникает вопрос, а получится ли послать IRP и получить
инфу в ответ. По описанию в МСДН эта функция используется, когда вышележащий дрйвер
посылает IRP ниже лежащему драйверу, но не на оборот.
И ничего не говорится про то, что так можно общаться с любым драйвером.
Здесь ведь случай такой, что мой драйвер и tcpip вобщем-то никак не связаны, неужель получится?
Здравствуйте, DimanKGKZ, Вы писали:
DKG>Здесь ведь случай такой, что мой драйвер и tcpip вобщем-то никак не связаны, неужель получится?
Получиться то получиться, если у Вас есть DEVICE_OBJECT, можете смело слать ему всякие IRP, никто Вас не ограничивает присутствием в стеке драйвера. В Вашем случае по-хорошему, конечно, так делать не следует, потому что у абстрактного драйвера лучше не вызывать диспетчерские функции при IRQL > PASSIVE_LEVEL, он может повести себя непредсказуемо, например, обратиться к свопируемой памяти. tcpip.sys вроде как "устойчив" к такому бесцеремонному обращению .
DimanKGKZ что то непонятно, что вам нужно сделать?
Вам нужно написать что-то типа фильтра сетевых пакетов на основе hook-драйвера. Так?
Что вы заморачиваетесь насчет выполнения каких-то действий на DISPATCH_LEVEL, которые требуют PASSIVE_LEVEL?
Синхронно получать инфу, которую вы хотите в сетевом обработчике у вас не получится. Поэтому как вам советовали разделите получение инфы в отдельных потоках или различных обработчиках.
Здравствуйте, onyx2, Вы писали:
O>DimanKGKZ что то непонятно, что вам нужно сделать? O>Вам нужно написать что-то типа фильтра сетевых пакетов на основе hook-драйвера. Так? O>Что вы заморачиваетесь насчет выполнения каких-то действий на DISPATCH_LEVEL, которые требуют PASSIVE_LEVEL? O>Синхронно получать инфу, которую вы хотите в сетевом обработчике у вас не получится. Поэтому как вам советовали разделите получение инфы в отдельных потоках или различных обработчиках.
Да , надо фильтровать тарфик, но кроме по портам еще и по процессам и юзерам их запустившим.
Был вариант при получении пакета получать инфу из tcpip табличку с портами и pid-ами.
Зная pid получаем инфу о запустившимся файле и юзере его запустившег. Ну а дальше дело техники .
Как оказалось кол-бэка функция работает на DISPATCH_LEVEL и нельзя поработать на PASSIVE_LEVEL
прежде чем эта функция вернет значение дропить пакет или пропускать.
Использовать разделение есть задача сложноватая... ну как вот отловить на любой момент времени
открылся/закрылся TCP/UDP порт, самы важный сейчас у меня вопрос?
Варианты есть конечно, но все какие-то не надежные...
Второй драйвер писать типа tdi-фильтр или там отлавливать API-функции создания/уничтожения сокетов...
И то и другое поливается грязью куда не сунься
Уж очень заманчиво было все сделать не вылазия из своего драйвера да еще в той-же кол-бэк функции
. Да и сама идея абсурдна — заставить ждать код на DISPATCH_LEVEL.
