Forum Replies Created
-
Posts
-
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).
Localhost Monitor API is created as a sniffer tool, not the firewall software and can’t be used fot the dropping packets. However, it’s base driver (TDI filter driver) can be used for the developing the application level firewall like the one you have mentioned.
You have NDISWANIP interface even if you have no modems installed. Please reference the interface list returned by ListAdapters tool.
I only have one adaptor in the PC. So everything must go through that network card.
If you have single ethernet interface then it does not mean that you have the only adapter seen by WinpkFilter, because you always have the dial-up(NDISWANIP) interface.
If i put the adaptor in to tunnel mode and dont have SendPacketToAdapter or SendPacketToMSTCP then all packets should be dropped and no networking should function.
You are right, if you filter in tunnel mode and don’t reinject packets to stack then any network activity is disabled. I suppose something is wrong with your code, definitions or the network interface you filter.
I have the only idea, probably you filter the adapter different from the one used for the e-mail and network browsing.
