Пытаюсь расширить функционал tdi_fw драйвера, а именно:

при поступлении входящего соединения (TDI_EVENT_CONNECT handler), в обработчике нет возможности принять решение о том разрешить ли соединение или запретить..
Необходимо спросить об этом user-mode процесс, которые контроллирует драйвер.

Проблема собственно в том, что я не знаю как это сделать..
Насколько я понял — TDI_EVENT_CONNECT handler работает на IRQL Dispatch, поэтому нельзя тупо отправить запрос в юзер-мод, и ждать ответа каким-нибудь KeWaitForSingleObject, так?

При этом, если TDI_EVENT_CONNECT handler возвращает что-то отличное от STATUS_MORE_PROCESSING_REQUIRED (например я пробовал вернуть STATUS_PENDING) — соединение прерывается.

А нужно, чтобы вопрос о том установить соединение или нет как-бы подвис на время, пока не придет ответ от user-mode приложения.

Подскажите как решить проблему?

Здравствуйте, ratix, Вы писали:

R>при поступлении входящего соединения (TDI_EVENT_CONNECT handler), в обработчике нет возможности принять решение о том разрешить ли соединение или запретить..
R>Необходимо спросить об этом user-mode процесс, которые контроллирует драйвер.

R>Проблема собственно в том, что я не знаю как это сделать..
R>Насколько я понял — TDI_EVENT_CONNECT handler работает на IRQL Dispatch, поэтому нельзя тупо отправить запрос в юзер-мод, и ждать ответа каким-нибудь KeWaitForSingleObject, так?

Так. Да даже если бы он вызывался только на PASSIVE_LEVEL, это не было бы правильным решением.

R>При этом, если TDI_EVENT_CONNECT handler возвращает что-то отличное от STATUS_MORE_PROCESSING_REQUIRED (например я пробовал вернуть STATUS_PENDING) — соединение прерывается.

R>А нужно, чтобы вопрос о том установить соединение или нет как-бы подвис на время, пока не придет ответ от user-mode приложения.

R>Подскажите как решить проблему?

Подскажу один из вариантов — посмотрите на последний аргумент ClientEventConnect.
Для этого IRP можно установить completion routine, и в ней отложить завершение,
отправив сигнал в user-mode. Получив ответ, завершение IRP возобновляется с
подходящим кодом, разрешая или запрещая прием соединения (TDI_ACCEPT).

R>Пытаюсь расширить функционал tdi_fw драйвера, а именно:

Доколе?!
Пора бы на WFP переходить.
И уже давно пора, между прочим.

Здравствуйте, x64, Вы писали:

R>>Пытаюсь расширить функционал tdi_fw драйвера, а именно:

x64>Доколе?!
x64>Пора бы на WFP переходить.
x64>И уже давно пора, между прочим.

и рад бы, да чертов backward compatibility мешает.. XP еще очень даже жива..

Здравствуйте, okman, Вы писали:

O>Подскажу один из вариантов — посмотрите на последний аргумент ClientEventConnect.
O>Для этого IRP можно установить completion routine, и в ней отложить завершение,
O>отправив сигнал в user-mode. Получив ответ, завершение IRP возобновляется с
O>подходящим кодом, разрешая или запрещая прием соединения (TDI_ACCEPT).

в целом — это вроде бы работает, но есть недочет: Если в completion routine принимается решение о блокировке соединения, то соединение разрывается. А хотелось бы чтобы эффект был такой, как будто соединение и не устанавливалось вовсе. Т.е. в текущей реализации, если я телнетом лезу на машину на которой работает фильтр, и соединение блокируется — telnet говорит "Connection lost", а хотелось бы чтобы он говорил, что Connection failed или timed out..

я так понимаю, всетаки предложенный вариант решения проблемы слишком поздно принимает решение о блокировке (когда TCP сессия уже завязана). Есть ли еще какие способы решения проблемы?

R>я так понимаю, всетаки предложенный вариант решения проблемы слишком поздно принимает решение о блокировке...

Да.

R>...когда TCP сессия уже завязана

Нет, сессия ещё не создана, проблема с TDI-фильтром в том, что независимо от того, что вернёт EventConnect-функция, tcpip.sys так или иначе даст о себе знать другой стороне.

R>Есть ли еще какие способы решения проблемы?

Чтобы сделать узел "невидимым", необходимо писать NDIS-фильтр.