Forum Replies Created
-
Posts
-
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.
There may be 2 application which are accessing same IP/ port/ protocol like Netscape and Internet explorer accessing yahoo.com same time.
Right, destination IP/protocol/port can be the same, but source ports will be different for the case described.
IMHO, in theory (hardly likely that it will ever happen in real life) it is possible that application running on NAT system access the same IP/port as another application running behind the NAT and the same source port used in NAT table and for local application running on NAT system. In this case it is not possible to distinguish if packet should be NAT’ed or not. But even in this rare case you still can use sequence and aknowledgement fields in TCP header to determine wheather the NAT should be applied (it will work for TCP connection only).
