Forum Replies Created
-
Posts
-
It seems that Packet Filter driver is not able to correctly understand packets that are biggers than 1400 bytes.
Well, Ethernet packets can be up to 1514 bytes length and these packets can be processed by WinpkFilter even if they are of maximum size. What exactly problems have you met with processing large packets?
Ok some more info… I ran into the exact symptom of deadlock on another machine. This one did not have Odyssey client or Cisco VPN. Rather, it had Microsoft Firewall enabled on the network interfaces. I turned off the firewall and haven’t seen a lock occur so far.
Probably this is some other sort of software you use on both of these systems. It is impossible to say more without deep analysis of drivers installed. Windows Firewall should not make any problem.
Another thought I had is how well does the framework work with power management. I had let the system sit sniffing packets for awhile and the power stuff kicked in to turn off the monitor. Would the OS be foolish enough to power down the NIC even though it’s hooked and still getting packets?
WinpkFilter intercept binding between protocol and NIC driver and not the NIC itself. So if OS will turn off the NIC you won’t see any packets from this NIC until OS power it back on.
Hmm, we have not heard of incompatibilities with these particular software, but it is still possible. It can be Cisco VPN (though if it is I guess we’d heard about this before but we did not) or Odissey (most probably because I’ve never heard about this software). The only way to get the exact answer is uninstall each of these services and check if problem is gone.
For the cases when incompatibility raises you still have an option to use NDIS IM version of WinpkFilter. It is less convenient in installation but it should not conflict with any similar software by design. NDIS hook is widely used but we can guarantee only the compatibility with WinpkFilter derived solutions, other third-party drivers may break WinpkFilter functionality as it is noted on the product homepage.
Well, I have not tried to install IE7, but WinpkFilter x64 build is based on the standard NDIS Intermediate driver (after Patch Guard was introduced making a NDIS hooking solution is possible but very difficult to support) and it is installed through the documented system mechanism.
If MS decided to reconfigure the network on some way during IE7 installation what involves reinstalling NDIS IM drivers (and probably some other network drivers) then I don’t think we can do anything about it except signing driver with WHQL or disabling unsigned drivers policy (as far as I understand you got “unsigned driver warning”, otherwise system would reinstall it without asking you).
Looks like a dead lock on the driver level (conflict with another NDIS-hook driver). What kind of VPN are using? Is it built in Windows VPN or third party one? Do you use any third party firewalls on that system?
is it possible that the fregments are the reason of this problem?
how should i manage the fregment packets? manage the WinpkFilter driver the fregments?The packet you introduced just is not IP packet at all. It can be ARP/RARP, IPX or anything else. Don’t forget to check protocol field in Ethernet header before parsing an arbitrary packet. And no, this can’t be an IP packet fragment, each of the fragments has a correct IP header.
Is the IM driver liable to break in Vista whenever MS patches the OS?
As far as I know IM drivers were not declared depreciated in Vista, so probably they won’t be unexpectedly dropped in one of the forthcoming SPs.
Will Vista support be upgraded to use the native Windows Filtering Platform or do you have a timetable when that might be rolled in?
WPF is relatively new and I would refrain from using it until Vista finally released along with final new WDK. The only WPF sample from beta WDK I seen so far was not able to send requests (NdisRequest) to the underlying NDIS miniports. May be it will be fixed (or even already fixed) but in the meantime it is a serious limitation.
I’m sorry but there are no public WinpkFilter builds with Vista x86 support available for download. The normal x86 package you could get from this site supports only Windows 9x/ME/NT/2000/XP/2003.
Windows Vista (both x86 and x64) are supported by NDIS IM build of WinpkFilter. In the meantime WinpkFilter NDIS IM used only for Windows XP/2003 x64, but it can be also compiled for x86 and used on Windows Vista x86. As soon as Vista is released for public we will add new WinpkFilter installation packages for public download (in the meantime it is available only to registered customers on special request for testing purposes).
WinPkFilter IM Driver seems to work with Vista
Yes, it does. Just need to fix the conversion of internal adapter name to user friendly one, but it can wait till Vista release.
I have signed the driver image, but Windows still complains about an unsigned driver. Do I have to package inf and sys files to a .cat file? Perhaps anybody has a short hint for me?
Have not tried myself yet, but as far as I understand you have two options, one is creating .cat file and another is embedding signature into the driver image. This papaer from MS covers some of the details:
http://www.microsoft.com/whdc/winlogo/drvsign/kmcs_walkthrough.mspx
Probably you can use raw winsock interface. Basically WinpiFilter allows you to query local MAC address, for getting MAC address for remote system you’d have to generate an ARP request packet and then process ARP reply one.
MSTCP is the name of TCP/IP protocol on Windows 9x/ME, but in context of WinpkFilter it is used to specify Microsoft TCP/IP module on Windows systems.
Sending packets to MSTCP means that packet will be indicated to TCP/IP stack from the name of the specified network interface (just like this packet would arrive to this network interfcae from the real network). By other words packet is injected into the upstream between network card and TCP/IP stack.
Sending packets to adapter means that packet will be sent directly to network interface from the name of TCP/IP protocol. By other words packet is injected into the downstream between TCP/IP and network card.
when i start to log all packets with NetFirewall it only showes TCP and UDP connections.
does it means that the firewall only manage this two protocols?NeT Firewall works just below TCP/IP and processes all IP protocols (IP, ICMP, IGMP, TCP, UDP and etc…). Probably you had not any other protocols activity when the log was collected.
when i setup my adapter to “High Security Level”.
does the programm blockes all other protocols which are not listed in the Security Rule table to allow this one ??“High Security Level” blocks every packet unless there is an allow rule matching this particular packet
what happen with IP, IGMP, RAW….. packets?
If there are no allow rules configured to pass these protocols then these packets are blocked on “High Security Level”.
В смысле С.С++ обьявления идентичны, единтсвенное по разному массивы приходится адресовать. А вот в случае C# интерпретация похоже отличается. Ну тут надо смотреть отладчиком что да как…
Сложно сказать (не являюсь поклонником С#), но предположить можно. Драйверу то все равно что за кусок памяти ему передали, он с ней работает как со структурой языка C и соответтвенно заполняет данными. Так что тут дело в том как C# интерпретирует полученную бинарную структуру, а он похоже то же самое обьявление интерпретирует по другому (возможно где-то неявно доставляются элементы, которых обычный С/C++ не добавляет). Думаю не ошибусь если предположу что в C# еть какое-то обьявление которое может заставить компилятор интерпретировать структуру как структуру С, а не managed C#. Что-нибудь подобное extern “C”, ведь как-то стандартные Win32 структуры обрабатываются нормально, думаю стоит посмотреть хидеры.
I have started to use SerpentFly’s suggestions, thus:
PEPROCESS pEprocess = PsGetCurrentProcess();
HANDLE SectionHandle = pEprocess->SectionHandle;I guess you are going to create a driver which supports all NT operating systems, so first of all you have to determine operating system version and then depending of it use the matching EPROCESS definition (from one post above). An example for Windows 2000 it would be as the following:
PEPROCESS_W2K pEprocess = (PEPROCESS_W2K)PsGetCurrentProcess();
HANDLE SectionHandle = pEprocess->SectionHandle;
