Forum Replies Created
-
Posts
-
WinpkFilter installation scripts (for Windows 2000/XP/2003) were updated in order to support compatibility with the latest released version of Kerio Personal Firewall. Details: Group:”Network” Start:0 were changed to Group: “Streams Drivers” Start:1.
WinpkFilter 2.4.1 released. This service release improves WinpkFilter support for some network interfaces (an example BUFFALO LPC4-CLX Fast Ethernet Adapter) under Windows 2000 and Millennium Edition. MS Visual Basic samples were also moved into the main package.
If you are eligible for a free update, please send the following details to support@ntkernel.com tо receive an update instruction:
1) Your order ID.
2) An approximate date of purchasing.Hmm, but which IOCTL’s you are interested in? An example, do you need capture IOCTL’s over DeviceIp and DeviceMULTICAST? These devices also allow sending packets; an example DeviceIp is used for sending ICMP packets (ping.exe->ICMP.DLL->DeviceIp). But in general I don’t think that you really need all that stuff.
The firewalls you have mentioned use NDIS-hooks and I don’t think that their drivers are WHQL certified. An example, ZoneAlarm uses technology based on some undocumented NDIS structures which can be changed by MS anytime. Do you think that such driver can be WHQL? However, NDIS hooks is still the most effective way to desigh the firewall kernel, and that fact that MS officially don’t recommend this is not enough to stop using it.
Hardly likely that NDIS-hooking driver can be WHQL, but I don’t know for sure. In any case the question of certification is usually the question of money you can pay for it. In order to avoid additional problems I think you will need to create NDIS IM driver for XP if you really need certication.
Normally TCP/IP for the Ethernet uses the following flags combination:
NDIS_PACKET_TYPE_BROADCAST | NDIS_PACKET_TYPE_DIRECTED | NDIS_PACKET_TYPE_MULTICAST;I’m not sure how usage of NDIS_PACKET_TYPE_ALL_LOCAL breaks the functionality but the request to set this filter is sent directly to the NDIS. However, why do you need this filter? Is there any OS dependence where filter works (an example works on XP but don’t work on Windows 2000)?
P.S. Please confirm that you have received your order, since it may appear that our e-mails can’t reach you.
Q: netbt.sys calls tcpip!TCPSendData directly. How can this be explained?
A: Yes, that’s true, tcpip.sys can be requested for the pointer to the internal routine tcpip!TCPSendData. You can see the processing of the particular request (IOCTL_TDI_QUERY_DIRECT_SEND_HANDLER) in reversed engineered code of tcpip!TCPDispatch. This interface improves performance of kernel-mode tcpip.sys clients.
The solution is interception of IOCTL_TDI_QUERY_DIRECT_SEND_HANDLER, saving the TCPSendData pointer and modification of the returned pointer to your own routine. So you can track all calls to TCPSendData.
I think you’d better reference some book or RFC for this question. In general TCP session established in three steps:
1) SYN-packet (TCP packet with SYN flag set) from client to server.
2) ACK-SYN packet from server to client
3) ACK packet from client to server.It’s difficult to comment this since I don’t know what is NDIS3PKT you use. However, if checking unchecking it fixes the problem then it may appear to be the problems reason. It looks that WinpkFilter is stable, since you don’t need to reboot the system in order to restore the functionality. Of course problem can be in the application, if it will stop reading packets from WinpkFilter you will get the “frozen LAN” effect.
Normally if you have enabled routing on the NAT system and if you can see ICMP req coming to the inner interface then this ICMP req should be routed to the external interface (WAN (PPP/SLIP) Interface if I understand your configuration). If you can’t see this packet anymore then probably the normal behavior is broken. It can be coused by enabled native XP connection sharing, firewall or third party NAT/gateway software. I suspect that this is rather the firewall which just drops ICMP packets but I can’t know it for sure.
Following to your post Send out modified ip packets, but no reponse ( NAT ) you read the packet from the inner interface, substitute the source IP and send this packet to the stack. What do you think the stack will do with packet received from the inner interface which has it’s own IP address as a source address? Yes, it will drop it, because it never expects such a packet from the network. So you don’t need to alter incoming packets from the inner interface. In this case TCP/IP will route them and try to send from the external interface with inner client source IP.
In order to complete your task you should filter the external (Internet interface) and NAT (substutute the source address with external interface one) outgoing packets. For the packets received on the external interface you should do the reverse operation (change destination IP from the external interface IP to inner system one) if you find the required entry in your NAT table.
In order to analyze your code I would also need to analyze the environment it runs in. However, check if you have enable IP routing (forwarding) since it is disabled by the default and TCP/IP will just drop the packets from the interface if they don’t match interface address information.
Another ques: when I call SendPacketToMstcp(), should I also get this packet at PACKET_FLAG_ON_SEND at the other adapter when MSTCP send it to interface? I tried, but not get the packet.
No, this flag has informational purpose only (for you reference if packet was received from the network or from the stack).
