Можно ли портировать драйвер протокола NDIS (npf.sys WinPcap) в LWF или WFP?

все. Я делаю некоторые улучшения для WinPcap. Теперь я перенес драйвер npf.sys с NDIS5.0 на NDIS6.0. Есть ли еще место для улучшения этого драйвера, например, для переноса его на LWF (облегченный фильтр) или WFP (платформа фильтров Windows)? Мы просто хотим использовать более новый и лучший фреймворк.

Вот еще вопросы:

Кажется, что LWF — это продукт времен Vista, а сейчас Microsoft его мало упоминает, так ли это?

Может ли драйвер LWF или WFP делать то, что может драйвер протокола NDIS?

Имеет ли LWF или WFP отношение к WDF (Windows Driver Framework) или они совместимы как с WDF, так и с WDM?

Если это жизнеспособно для переноса, как насчет сложности, я уже разработал некоторые промежуточные драйверы NDIS, сложнее или проще LWF или WFP?

Спасибо!


person Yang Luo    schedule 06.08.2013    source источник


Ответы (1)


Поздравляем с переносом WinPcap на NDIS 6.x. Я впечатлен. Надеюсь, вы сможете убедить апстрим принять ваши изменения :-)

Что касается LWF

LWF по-прежнему поддерживаются Microsoft. Мы мало о них говорим просто потому, что интерес к ним ограничен. Большинство людей действительно хотят работать на уровне 3 или уровне 4, где их лучше обслуживает WFP, чем LWF. Однако инструментарий низкоуровневого захвата пакетов является прекрасным примером того, для чего хороши LWF.

Мы рады видеть, что люди пишут новые LWF, вызовы WFP, минипорты NDIS или протоколы NDIS. Это все поддерживаемые и современные технологии. (Предполагая NDIS 6.x для минипорта и протокола).

Сравнение LWF, протоколов NDIS и вызовов WFP

LWF может делать почти все, что может делать драйвер протокола NDIS. Есть несколько небольших угловых случаев, но в целом вы обнаружите, что LWF являются мощными.

Вызовы WFP работают на другом уровне и поэтому имеют несколько иные сильные и слабые стороны, чем протокол NDIS или LWF. Например, вызов WFP не может взаимодействовать с состоянием подключения к мультимедиа, разгрузкой оборудования или управлением питанием. Но, в отличие от LWF NDIS, вызов WFP может просматривать открытый текст пакета, защищенного с помощью IPsec, запрашивать личность пользователя/приложения, которое первоначально отправило пакет, перехватывать петлевой IP-трафик и авторизовывать создание самого сокета (до любого трафик отправляется).

Вы должны сесть и спросить себя: "Какой уровень сетевого стека меня действительно интересует?" Если ответом является уровень 2, используйте драйвер NDIS. Если это уровень 3 или уровень 4 стека IPv4/6, вам понадобится выноска WFP. (Некоторые люди начинают с драйвера NDIS, потому что они лучше всего знакомы с NDIS, но затем сталкиваются с трудностями, потому что на самом деле пытаются решить проблему на уровне TCP.)

Использование WDF с NDIS или WFP

WDF в значительной степени ортогонален NDIS или WFP. Вы можете использовать либо WDF, либо WDM, либо их сочетание в драйвере NDIS или вызове WFP. Microsoft, команда NDIS и я официально рекомендуем вам как можно чаще использовать WDF, поскольку это сэкономит ваше время и повысит качество вашего драйвера.

Как правило, если ваш протокол LWF или NDIS является просто базовым драйвером «hello world», WDF будет работать нормально, но не будет очень полезным. WDF мало помогает в той части вашего драйвера, которая взаимодействует с NDIS. Но как только вы добавите IOCTL в пользовательский режим (или любой другой трюк, не относящийся к NDIS), WDF может сэкономить вам много времени и ошибок.

Сложность вызовов LWF и WFP

Я думаю, вы обнаружите, что NDIS LWF и вызовы WFP являются одними из самых простых для написания сетевых драйверов. LWF проще, чем драйвер протокола NDIS, и намного проще, чем драйвер NDIS IM. Полный драйвер LWF без каких-либо действий состоит всего из 20 строк кода. Выноски WFP писать не сложнее, чем LWF.

person Jeffrey Tippet    schedule 06.08.2013
comment
Еще раз спасибо за ваш ответ, Джеффри :) WinPcap - это в основном программное обеспечение для захвата пакетов уровня 2, поэтому я думаю, что вызов WFP (обратный вызов) можно исключить. Так что, возможно, 1) протокол NDIS6 и 2) NDIS LWF — это два альтернативных варианта, из которых мы можем выбрать. Какой лучше? - person Yang Luo; 07.08.2013
comment
Некоторые сомнения от себя здесь: 1) хотя драйвер LWF несколько проще, чем протокол NDIS, но при условии, что у нас уже есть готовый драйвер протокола NDIS, миграция на LWF потребует больше усилий. 2) как насчет функциональных возможностей, я знаю, что LWF может отклонить пакет, который не может сделать протокол NDIS, но это также не то, на чем фокусируется WinPcap, если есть другие функции, такие как обработка пакетов обратной связи (ping 127.0.0.1), которыми может владеть LWF ? 3) как насчет производительности. Кто-то сказал мне, что протокол NDIS более неэффективен, чем NDIS LWF и даже драйвер NDIS IM? - person Yang Luo; 07.08.2013
comment
Что ж, если у вас есть работающий протокол NDIS, это 100 баллов в пользу протокола NDIS. Однако с точки зрения архитектуры я бы предпочел NDIS LWF. NDIS LWF легко выиграет по производительности, так как он не требует медленного обратного пути для захвата пакетов TX. LWF также могут видеть необработанные пакеты 802.11 (включая ответ зонда, кадры аутентификации и т. д.), которые протоколы не могут увидеть. - person Jeffrey Tippet; 08.08.2013
comment
Что вы имели в виду под принудительным медленным петлевым путем для захвата пакетов TX? Что такое TX-пакет? Я не очень хорошо понял. Кроме того, насколько я знаю, используемый в настоящее время WinPcap может захватывать беспроводные пакеты, поэтому пакеты 802.11 могут быть видны протоколу NDIS? Спасибо - person Yang Luo; 08.08.2013
comment
TX — это путь отправки, он же выход. RX — это путь приема, он же вход. Если один протокол отправляет пакет (путь TX), NDIS необходимо выполнить много дополнительной работы, чтобы передать этот пакет на путь приема другого протокола (путь RX). Это медленный петлевой путь. (Жаль, что у меня не было доски, чтобы нарисовать это....) - person Jeffrey Tippet; 08.08.2013
comment
WinPcap может видеть данные пакетов 802.11, но не видит специальные кадры управления 802.11. В протоколе 802.11 есть куча дополнительных кадров, которые являются частью уровня 2 и никогда не дополняются протоколами. Эта страница дает неверное (или, по крайней мере, устаревшее на 10 лет) объяснение проблемы: wiki.wireshark.org/CaptureSetup/WLAN#Windows . Но если вы используете Microsoft Network Monitor, который является LWF, вы можете захватывать эти специальные кадры управления 802.11. - person Jeffrey Tippet; 08.08.2013
comment
Кажется, что драйвер LWF (я нашел официальную фразу: NDIS Filter Driver, которому принадлежит больше ссылок в Google) выигрывает у протокола как по производительности, так и по функциональности. Действительно, я немного беспокоюсь о том, есть ли у меня еще достаточно времени, чтобы закончить драйвер LWF в течение временного промежутка Google Summer of Code. Вот почему я немного склоняюсь к готовому к использованию протоколу. Но теперь я решил попробовать LWF :) - person Yang Luo; 09.08.2013