Forum Replies Created
-
Posts
-
Vista is relatively new stuff and I can’t advise much about it. However I would try to set a debug privilege for the GUI process instead of editing ACL.
Hmm, in the meantime firewall driver interface is not open for public. However I understand your requirements and if you are a licensed user then please send an e-mail to support(at)ntkernel.com. I don’t see any objections to open firewall interface to licensed users. Please note that firewall API is a C++ DLL which is a wrapper around driver I/O control codes. You should be able to use it from managed C++ (if make C style wrappers then from any environment which support calling functions from C DLL).
Some filtering techniques overview can be found here http://www.ntkernel.com/w&p.php?id=14
You can use drivers IOCTL interface in kernel mode, though it would be far easier to modify the original driver to add the functionality you need.
Well, first of all WinpkFilter x86 standard build (NDIS hook based) you probably downloaded from this site ignores IPv6 protocol (you still can see incoming IPv6 packets as they are also delivered to IPv4) and works with IPv4 only. Though it can be easily extended to support IPv6, but it require rebuilding driver binary. Such sort of modification is available to licensed users.
x64 standard build also available from this site is based on NDIS IM driver and by default it works with both IPv6 and IPv4.
WinpkFilter has an internal packet pool for 500 packets. This size was chosen according real networking requirements and can be changed. If this pool is too large it is just waisting of memory, if it is too small it may decrease real network performance. In your test cases these 500 packets were not enough for such high sending rate and many packets were just dropped by WinpkFilter.
TCP is very different from UDP, it won’t send more packets than fit in maximum window size before receiving receipt confirmation. So such situation like you got with UDP is not possible.
1514 bytes is a network media limit for 802.3 Ethernet (actually it is 1518 bytes but two extra bytes exist only on the physical media and not visible by software). 14 bytes are used for Ethernet header, so maximum IP MTU is 1500 bytes. All IP packets above this size are fragmented by TCP/IP stack. In your case 7900 bytes UDP packet will be fragmented to 6 IP packets and only first fragment will contain UDP header. You can reconstruct the packet from fragments received from WinpkFilter driver if you need to do so.
Some modern network cards (Gigabit Ethernet) may support frames larger than 1514 bytes (9000 bytes “jumbo frames”). WinpkFilter driver can be extended to work with these larger frames (default on site build does not support them and limits MTU to normal 1514 bytes), but I don’t think this is your case, correct me if I’m wrong.
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).
