NDIS LWF — FilterRestart и FilterPause

Question

Я новичок в драйверах NDIS LWF, но мне пришлось перейти на них после того, как я определил, что WFP на Win7 не соответствует моим требованиям.Надеюсь, это не слишком простой вопрос.

Мои требования в основном предполагают возможность беспорядочного прослушивания выбранного сетевого адаптера в системе с несколькими сетевыми адаптерами.Я изменил образец LWF, чтобы перевести интерфейсы в неразборчивый режим, но теперь застрял в том, как установить указанный адаптер.Я понимаю, что LWF находится поверх всех адаптеров, поэтому это не протокол, в котором я мог бы просто вызвать NdisOpenAdapterEx, но я предполагаю, что должен быть какой-то механизм фильтрации, чтобы игнорировать определенные адаптеры.

Мне нужно иметь возможность IOCTL для драйвера выбранных MAC-адресов интерфейса, который меня интересует.Можно ли загрузить драйвер, но фильтр будет работать только на определенных интерфейсах, или мне просто придется просто игнорировать вызовы, поступающие от других, которые меня не волнуют, в FilterReceiveNetBufferLists.Просто кажется, что было бы более эффективно не использовать обратный вызов FilterReceiveNetBufferLists, если я не буду ничего с ним делать для определенного интерфейса.

Меня сбивает с толку тот факт, что FilterRestart вызывается автоматически во время DriverEntry (через NdisFRegisterFilterDriver) и что, похоже, нет NdisFPauseFilter (но есть NdisFRestartFilter).В идеале я хотел бы иметь возможность установить необходимые параметры до начала какой-либо фильтрации, и мне бы хотелось воздержаться от использования реестра во время DriverEntry, поскольку мне все равно понадобится возможность динамического перезадания по мере необходимости.

И, наконец, просто для лучшего понимания внутреннего устройства NDIS: когда модуль фильтра приостанавливается, приостанавливается ли весь стек или NDIS маршрутизируется вокруг приостановленного модуля?

Answer 1

Это хорошие вопросы.

Можно ли загрузить драйвер, но фильтр будет работать только на определенных интерфейсах?

Да.Здесь у вас есть три варианта.

1. Статически отключить привязку в пользовательском режиме;или
2. Отклоните привязку во время выполнения.
3. Динамический обход и повторное включение пути данных.(Здесь это не будет подробно описываться, поскольку это уже описано в MSDN.)

Чтобы статически отключить привязку, вы должны использовать API-интерфейс INetCfg чтобы найти привязку между драйвером фильтра и сетевой картой, а затем отключите ее.Это может выглядеть так:

INetCfg::Initialize
myFilter = INetCfg::FindComponent
myFilter->QueryInterface(INetCfgComponentBindings)
for each binding in bindings
    if binding is to undesirable NIC
        INetCfgBindingPath::Enable(FALSE)

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

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

Как отказаться от привязки во время выполнения?Во многих случаях все, что вам нужно сделать, это вернуть статус сбоя с вашего FilterAttach обработчик.Этого достаточно, чтобы убедить NDIS в том, что ваш фильтр не может (или не будет) подключаться к сетевой карте.Но — если ваш фильтр помечен как Обязательный (т. е. FilterRunType INF равен 1), то в случае неудачи FilterAttach приведет к тому, что сетевой адаптер станет неработоспособным.(Ведь это весь смысл быть обязательным.Если ваш фильтр отсутствует, то путь к данным не должен run.) Но если вы хотите, чтобы сетевой адаптер все равно начал работу, установите NDIS_FILTER_ATTACH_FLAGS_IGNORE_MANDATORY флаг в твоем NDIS_FILTER_ATTACH_PARAMETERS::Flags поле непосредственно перед тем, как ваш фильтр вернет код ошибки из своего FilterAttach.

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

Ваши инстинкты верны.Наличие фильтра в тракте данных требует дополнительных затрат, и если фильтр ничего не делает, это приводит к потере циклов ЦП.Но пока не списывайте этот вариант со счетов.В некоторых случаях простота этого варианта перевешивает его (относительно небольшую) стоимость процессора.То есть, если ваш целевой рынок не считает каждый цикл процессора, возможно, будет достаточно просто использовать этот простой вариант.

Я бы хотел воздержаться от использования реестра во время DriverEntry, потому что мне все равно понадобится возможность динамического перезадания по мере необходимости.

Как уже говорилось выше, вы может повторите задачу с кодом пользовательского режима.Каждый раз, когда пользовательский режим вызывает INetCfg::Apply, NDIS вызывает любой FilterAttach или FilterDetach необходимо, чтобы произошли правильные изменения.

При использовании второго метода перезадать задачу на самом деле невозможно.Если вам необходимо переназначить конкретную сетевую карту, вам следует использовать первый или третий метод.

когда модуль фильтра приостанавливается, весь стек приостанавливается или NDIS маршрутизируется вокруг приостановленного модуля?

Весь стек приостановлен.NDIS не «обходит» фильтры.(Если ваш фильтр является необязательным, трафик будет обходить ваш фильтр, когда он не работает.Но пока ваш фильтр подключен к сетевому адаптеру, NBL и OID будут проходить через ваш фильтр.)