Forum Replies Created
-
Posts
-
How do other people get these files?
Commercial licenses of WinpkFilter are also available and do include all required redistributables.
Quote from WinpkFilter run-time license:
WinpkFilter 3.0 Runtime Libraries is provided as freeware for private (non commercial), or educational (including non-profit organization) use.It may not be distributed for profit, nor may it be included in products or otherwise distributed by commercial entities to their clients or customers without the prior written permission of the author.
So basically WinpkFilter run-time is not supposed to be used for creating redistributable WinpkFilter based software and therefore does not install all redistributable components.
What’s about your WinpkFilter – Framework?
WinpkFilter operates at the NDIS level and can’t associate packet with PID without any additional information.
I just saw your Local Network Monitor API, that seems to be the right stuff?
You are right, Local Network Monitor API can be used for this.
but,I don’t know whether NeT Firewall is a Stateful-inspection firewall
Yes, it is stateful inspection firewall 8)
I have checked your software configuration and I would say that you have a pretty large amount of various low level network software and among other things there is neofltr_600_12507 Juniper Networks TDI Filter Driver (NEOFLTR_600_12507). This can be a reason for software conflict. As you may noticed we try to fix incompatibilities with 3rd party TDI filters (like the latest 2.2.5 release was relative to compatibility with TDI filter from McAfee). Of course the best approach would taking a fresh OS installation and adding software until the problem appears.
Looks like some sort of software conflict. Please e-mail winmsd output to support(at)ntkernel.com, it may shed some light.
I know at least several widely used software products which use LNM engine. At least one of them is used for database monitoring. So I would say this is realistic.
Try using Local Network Monitor to avoid the possibility that you use incorrect filters combination.
I can see only two possibilities:
1) Incorrect set of filters loaded
2) Software conflict with some third party firewall applicationIt is difficult to say what was the exact reason. To avoid software conflict possibility I would recommend running the same configuration on the freshly installed OS without firewall/anti virus software because the last one can include own TDI filter which interfere LNM.
DWORD is defined as unsigned long which is a different type than unsigned int. Although both types has the same implementation (32 bit unsigned value) in MS Windows compiler generates an error.
You have two options to resolve this:
1) Change your thread function definition
2) Explicitly type cast the function pointerIm installing driver with snetcfg with ndisrd.inf and ndisrd_m.inf parameters but im using ndis hooking driver with delphi
NDIS hooking driver must be installed by adding registry entries, not by using snetcfg and INF files created for NDIS IM variant of the driver. Doing like you do would cause unpredictable behavior of the system. At least driver won’t work correctly if installed this way. So probably you use NDIS IM driver, not NDIS hooking one.
I used 3.0.2.1 version of ndisrd.sys
It is recommended to update to 3.0.4. NDIS IM driver included in 3..0.2 had some known problems with loopback packets processing and could be a reason of the BSOD mentioned.
I dont know another way of installing driver. I tried to write values into registery with my own installer, I got some errors on different machines with windows xp. How can I do clear install hooking driver automatically? Is there another script or etc? like snet cfg
I can send you a NSIS installer script for the latest build of winpkfilter for the reference if you want.
В описании WinpkFilter указано, что можно использовать RAW IOCTLs в своем драйвере. А есть ли пример драйвера?
Использовать можно, но никто еще, насколько я знаю, так не делал. Обычно клиенты либо не хотят лезть в ядро и делают все в user space, либо переделывают исходный драйвер (все варианты драйвера разделяют общий сегмент кода относящийся к обработке пакетов, все изменения достаточно вносить в него). В общем-то возможность использования IOCTL интерфейса из ядра упомянута скорее для полноты картины, отдельного примера использования нет.
Какая примерно будет разница по производительности если использовать RAW IOCTLs либо встраиваться прямо в драйвер WinpkFilter?
Оценок не делалось, но накладные расходы при использовании IOCTL интерфейса довольно значительны. В качестве альтернативы, можно было бы экспортировать набор функций из winpkfilter драйвера и предусмотреть регистрацию callback функций – это работало бы быстрее. Но опять же, поскольку никто подобной возможностью не интересовался (дополнительный функционал обычно добавляется по востребованности), она не была добавлена.
Hi,
Thank you for reporting this. I’ve got a few questions:
1) WinpkFilter NDIS hooking variant is installed directly through the registry. snetcfg is only applicable to NDIS IM variant of WinpkFilter. Which driver have actually used?
2) What version of WinpkFilter have you used? Prior 3.0.4 WinpkFilter NDIS IM driver may have meet problems with loopback packets processing which would cause the similar crash. This was fixed in 3.0.4.
3) What Windows version have you used? I’ve quickly tested Windows XP 32 bit with IPX installed and have not noticed problems with both NDIS IM and NDIS hooking drivers.
4) If you have any firewall(even integrated with AV)/VPN software installed then please let us know the name and the version, since this can be a software driver conflict.
