Forum Replies Created
-
AuthorPosts
-
WinpkFilter 3.0.5 released:
1) fixed compatibility issue with Kaspersky software
2) added API for getting active WAN connections information
3) added API for sending/receiving bulk of packetsImportant note:
For Windows Vista and later versions of the Windows family of operating systems, kernel-mode software must have a digital signature to load on x64-based computer systems. WinpkFilter drivers are not signed and in order to test them on Vista x64 you should press F8 during system boot and choose Disable Driver Signature Enforcement option. For the commercial software you’d have to obtain Code Signing certificate from Verysign or another Certificate Authority authorized by Microsoft.If you are eligible for a free update, please send the following details to support@ntkernel.com to receive an update instruction:
1. Your order ID.
2. An approximate date of purchasing.WinpkFilter 3.0.5 will be placed for public after pre-release testing completion.
Yes it is possible and this is the right way to drop packets.
So far only the packets statistics (packets this filter was applied to) is accumulated for loaded filters. There is no special event to indicate that the filter was triggered.
Ahh, you mean packets passed without being indicated to user mode. Well, since this packets are supposed to be passed with minimal performance affect they have to no event to trigger.
hi,admin,you said will release a new version in april,but now, is nothing. please please to going fast
Hopefully this week 🙂
It is possible to add a timestamp to packets if needed.
Если из Ring0 => из драйвера
XP x64 => драйвер 64 битный и ndisrd 64 битныйМежду 64 битными драйверами используем обычный INTERMEDIATE_BUFFER
INTERMEDIATE_BUFFER_WOW64 определена, чтобы из 32 битного приложения передать данные в 64 битный драйвер, при этом не меняя кода 32 битного приложения. Бинарная структура INTERMEDIATE_BUFFER собранная 32 битным компилятором отличается от INTERMEDIATE_BUFFER собранной 64 битным. Но бинарная структура INTERMEDIATE_BUFFER_WOW64 собранной 32 битным компилятором совпадает с бинарной структурой INTERMEDIATE_BUFFER собранной 64 битным. Теперь понятно???
Event set to driver through SetPacketEvent API is signaled immediately on packet send/receive event.
Ккие-то проблемы в вашем коде, никаких наложений и затираний быть не может, память под пакеты идет фиксированными буферами, даже если пакет 14 байт, то все равно под него выделено 1514.
А зачем все это? Структура INTERMEDIATE_BUFFER_WOW64 определена для внутреннего пользования (конверсии в случае 32 битного приложения и 64 битного драйвера). Приложение-клиент должно работать с INTERMEDIATE_BUFFER, все необходимые конверсии сделает NDISAPI если они будут нужны.
Нет там никакой структурки, это случайное дополнение – мусорные байты. В сеть можно закинуть пакет любого размера не превышающего допустимый сетевым адаптером, в случае ethernet общий размер пакета не может превышать 1514 байт. Если Iris видит пакет значит в сеть он ушел, можно его перехватить в точке назначения для верности. Другое дело что стек принимающей системы мог забраковать пакет, увеличение размера TCP данных не совсем тривиальная задача, нужно учитывать меняющиеся SEQ/ACK поля.
В любой сборке WInpkFilter кроме WinpkFilter run-time libraries.
I would recommend to drop the original request and form a new response packet with redirect.
Сделать можно, но готового функционала для шейпинга в драйвере нет. Нужно все сделать руками на уровне пакетов. Впрочем все это достаточно несложно, если есть понимание как должны работать правила.
-
AuthorPosts