Forum Replies Created
-
Posts
-
It looks like ctx->old_handler = NULL. You can inspect the code to check how could it happen, may be this is a sort of race condition.
1) According to the above scenario, can I use your WinpkFilter 3.x product to do it?
Sure you can.
2) Can I set a specific device adapter filter so that ONLY UDP packets going to a specific port are grabbed via a ReadPacket() call?
Yes, you can use built-in WinpkFilter filters for this.
3) Can I use the “listen” mode to grab the packets, and signal to DROP bad packets but let the good ones pass through? I really don’t want to have to re-send the good packets to the loopback address or use tunneling mode. I’d like to just drop the bad packets and let things be as normal for the good packets.
No, if you suppose to drop packets you should be filtering in tunnel mode. Listen mode only gives you a copy of the packet while passing the original one.
4) Can I open up multiple device adapter handles and set different filters for them so that simultaneous ReadPacket() calls return different packets based on the different filters?
Yes, you can open multiply adapters and set adapter specific filters.
5) Is there a way to not have to keep calling the ReadPacket() method inside of a loop? Like, set the adapter to execute a callback function when a new packet is on the buffer? This would support an event driven model which is much more efficient on the CPU.
Driver code can’t callback user mode code. If to be precise, you can execute a code in user mode part of the memory, but it can’t be safe (as packets arrive from the network at IRQL_DISPATCH_LEVEL but user mode memory can be paged out) and it also would be a security hole (as user mode code is executed with kernel mode privilege).
6) After reviewing your product documentation, I noticed there is no structure documentation for the Adapter structure that is used commonly throughout your product as an Integer Pointer Handle. You have all the other structures documented, why not this very important one? I figured it must be a common structure in NDIS, but after some research, I’m finding that driver developers start adding their custom fields to it. What is the WinpkFilter structure associated with individual Adapter handles, i.e “_ETH_REQUEST.hAdapterHandle” ?
This is internal WinpkFilter structure and it is not accessible from user mode (it is allocated from kernel memory).Thats why it is opaque.
VirtNet has hardcoded MAC address in driver, however you can easily changed it through the network card properties. Driver tries to read MAC address from the registry during driver start.
You can use WinpkFilter built-in filters to intercept only packets destined to port 80. For the intercepted packet you can get a pointer to packet data and search for the “explorer” string. If you modify the packet you have to recalculate packets TCP and IP checksums. Also, if you modify packet length you also have to affect TCP header.
I’m not experienced in C# well enough to inspect your code for possible errors. However, I would recommend you to install network sniffer like Network Monitor or Wireshark and intercept your handcrafted packets from the network. Network sniffer will show if anything is wrong with checksum.
Also, I can’t see in the code fragment where do you check if you are working with UDP packet. Or do you treat every outgoing packet as UDP one?
Try to run passthru sample on the same network interface for which you run wireshark and I think you will be able to get exactly the same capture.
WinpkFilter 3.0.7 released. This service release includes the bugfix for WinpkFilter NDIS IM driver on power state changes.
If you are eligible for a free update, please send the following details to [email protected] tо receive an update instruction:
1) Your order ID.
2) An approximate date of purchasing.You can use VirtNet under Windows x64 if disable driver signing requirement (press F8 during system boot and choose Disable Driver Signature Enforcement option) or you can use test signing for VirtNet driver.
For the cross platform compatibility WinpkFilter driver returns adapter names as ANSI strings (actually only ANSI set used for internal adapter names). On user mode level you can operate with UNICODE strings if needed, just remember that strings from driver are in ANSI.
It may happen if your packet processing code is incredibly slow. In this case internal driver packets queue reaches its maximum size and all newly coming packets are dropped.
If you use high speed connection I recommend to use ReadPackets API instead ReadPacket (refer PackThru sample) and optimize your packet processing code.
