2013-08-13 2 views
0

все. Это я снова, парень портировал WinPcap из протокола NDIS 6 на фильтр NDIS 6 :) Я столкнулся с ошибкой, которая задержала меня на два дня. Вот он: после того, как я установил драйвер npf6x.sys (оригинальный с именем npf.sys), услугу можно запустить с помощью «net start npf». Затем я открыл Wireshark. Затем сеть опустилась (восклицательный знак на значке в трее). После удаленной отладки я обнаружил, что процедура FilterReceiveNetBufferLists никогда не вызывается. Я считаю, что связь RX была нарушена. Однако FilterSendNetBufferLists вызывается нормально. Я уверен, что FilterAttach был успешно вызван, и теперь FilterUnload не вызывается. Поэтому модуль фильтра должен оставаться на своем месте. Но он просто не может работать на пути RX. Затем я нажал кнопку «Пуск» Wireshark, я неожиданно обнаружил, что сеть восстановилась. Затем я остановил текущий захват и нажал «Список интерфейсов», сеть снова опустилась. Это так странно.Почему мой драйвер фильтра NDIS 'FilterReceiveNetBufferLists обработчик не вызывается?

Я не изменил указатель обработчика в процессе работы драйвера. Кажется, что драйвер также не заблокирован замками. Может ли кто-нибудь сказать мне, есть ли какой-нибудь случай, чтобы NDIS не вызывал FilterReceiveNetBufferLists фильтра во время его работы?

Также есть какие-либо оффициальные документы, касающиеся адресации протокола NDIS 6 к фильтру NDIS 6? Я только нашел документы для портирования из NDIS 5 в NDIS 6.

спасибо.

ответ

1

У нас нет официальной документации по протоколу LWF->, поскольку это не очень общий переход.

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

  • Минипорт в нормальном состоянии? Убедитесь, что !ndiskd.miniport показывает все в ГОСУДАРСТВЕННЫЙ район, как зеленый или нормальный. Убедитесь, что датапат в норме (не отключен) и подключено состояние подключения к мультимедиа.
  • Загружается ли ваш драйвер фильтра, если вы считаете, что он должен быть загружен? Убедитесь, что !ndiskd.miniport: Раздел BINDINGS показывает ваш фильтр. Если вы используете новый WDK Windows 8.1, проверьте также, что привязка фильтра не «отклонена».
  • Предоставляет ли фильтр приема минипорта обычный набор входящих пакетов? Убедитесь, что !ndiskd.miniport -filterdb показывает, что минипорт имеет, по крайней мере, разрешенный трафик, на который наносится ПРЯМОЙ и МНОГОКРАТНЫЙ.
  • Является ли минипорт, показывающий трафик? Установите точку останова на ndis!NdisMIndicateReceiveNetBufferLists и убедитесь, что точка останова попадает часто, так как сетевой адаптер передает принятые пакеты в ОС.
  • TCPIP пытается отправить трафик? Если TCPIP не отправляет трафик, то ответов на получение не будет. Установите точку останова на ndis!NdisSendNetBufferLists, чтобы узнать, отправляет ли TCPIP какой-либо трафик. Если это так, установите другую точку останова на обработчике отправки минипортов (используйте !ndiskd.minidriver, чтобы найти обработчик MiniportSendNetBufferLists) и убедитесь, что пакеты отправки переходят к NIC.
  • Не пуста ли пул приемников минипорта? Если это так, минипорт не сможет указать больше пакетов, потому что в нем закончились NBL. Используйте !ndiskd.pendingnbls, чтобы узнать, есть ли какие-либо НБЛ, которые еще не были возвращены. Для него типично найти нулевую или, возможно, одну ожидающую NBL; если вы видите, что он находит сотни, то в вашем фильтре есть утечка NBL.
  • Не видел ли мини-отель каких-либо проблем? Проверьте статистику минипорта. В Windows 8 используйте Get-NetAdapterStatistics от PowerShell.

Если вы новичок в отладке сети ядра Windows, вам будет сложно определить, хорошо ли это выглядит или плохо. В идеале у вас есть другой рабочий компьютер для отладки, чтобы вы могли видеть, что такое «нормальный».

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

+0

Вот информация минипорт: Miniport Broadcom NetLink (TM) Gigabit Ethernet Выполняемые, ПРИВЯЗКИ: WinPcap NDIS Lightweight Filter-0000 8657a8f0 865ca008 85fc5000, после того, как я занесены «! Ndiskd.miniport -filterdb», я видел «85eb6b98 875230e0 Broadcom NetLink (TM) Gigabit Ethernet " – hsluoyz

+0

Также я нашел ndis! NdisMIndicateReceiveNetBufferLists никогда не вызывается. ndis! NdisSendNetBufferLists можно вызвать, когда я выхожу. в DebugView я видел, что есть только TX-пакеты и OID-запросы, а не RX-пакеты. После ввода «! Ndiskd.minidriver» я увидел «85eb6b98 - k57nd60x», я не видел обработчик MiniportSendNetBufferLists, но я не думаю, что здесь проблема, потому что я использовал другой компьютер для непрерывного тестирования тестовой машины. – hsluoyz

+0

После ввода «! Ndiskd.pendingnbls» вывод: PHASE 1/3: Найдено 23 пула (ов) NBL. ФАЗА 2/3: Найдено 55 освобожденных НБЛ. В ожидании Nbl В настоящее время проводится Не найдено ожидающих НБК. ФАЗА 3/3: Найдено 0 ожидающих NBL (-ей) 255 общего количества NBL (-ов). Поиск завершен. (похоже, все в порядке). Тест-машиной является Win7 x86, поэтому я не могу выполнить команду GetNetAdapterStatistics. – hsluoyz

Смежные вопросы