I am writing a NDIS IM software. The goal is to change the destination IP
address and port of the IP packet. For example, the original IP packet is
destinated to the 192.168.1.1:22, I want to change the destination
IP:port(192.168.1.1:22) to 192.168.1.2:22.
What do I do in the NDIS IM part:
(1) In the NDIS packet, change the detination IP from the original
192.168.1.1 to 192.168.1.2
(2) re-calculate the IP checksum
Then send the changed NDIS packet out.
Now the 192.168.1.2 can get the packet I send. But there is no ACK packet
back from the 192.168.1.2.
What’s wrong with my process? Help please. Thanks in advance.
Here is the output of the tcpdump,
19:59:38.517324 192.168.1.5.1803 > 192.168.1.2.ssh: S
2425191351:2425191351(0) win 64240 (DF) 19:59:41.462994 192.168.1.5.1803 > 192.168.1.2.ssh: S 2425191351:2425191351(0) win 64240 (DF) 19:59:47.498883 192.168.1.5.1803 > 192.168.1.2.ssh: S 2425191351:2425191351(0) win 64240 (DF)
I am sure the IP header checksum is right.
I do not recalculate the TCP header checksum. Since only the destination IP
in the IP header has been changed(both port are 22 in the test), so I think
there is no need to recalculate the TCP header checksum. Am I right on this?
----- Original Message -----
From: “sevenyears” To: “Windows System Software Devs Interest List” Sent: Thursday, March 18, 2004 6:46 PM Subject: Re: [ntdev] No ACK in NDIS IM Forwarding
> are you sure your checksum of packet, such as ip header chksum and tcp > header chksum be changed and recalculate right? > > > > — > Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256 > > You are currently subscribed to ntdev as: xxxxx@wtwh.com.cn > To unsubscribe send a blank email to xxxxx@lists.osr.com > >
I thought the whole header was checksummed, but I could be wrong… So if
you change the anything in the header, you need to recalculate the checksum.
Why not just calculate the checksum for a unchanged and changed header, and
see if they are different. You could probably do this by hand if you don’t
like writing code to do it…
–
Mats
-----Original Message-----
From: Xia Tao [mailto:xxxxx@wtwh.com.cn]
Sent: Thursday, March 18, 2004 12:06 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] No ACK in NDIS IM Forwarding
I am sure the IP header checksum is right.
I do not recalculate the TCP header checksum. Since only the
destination IP
in the IP header has been changed(both port are 22 in the
test), so I think
there is no need to recalculate the TCP header checksum. Am I
right on this?
----- Original Message -----
From: “sevenyears” > To: “Windows System Software Devs Interest List” > Sent: Thursday, March 18, 2004 6:46 PM > Subject: Re: [ntdev] No ACK in NDIS IM Forwarding > > > > are you sure your checksum of packet, such as ip header > chksum and tcp > > header chksum be changed and recalculate right? > > > > > > > > — > > Questions? First check the Kernel Driver FAQ at > http://www.osronline.com/article.cfm?id=256 > > > > You are currently subscribed to ntdev as: xxxxx@wtwh.com.cn > > To unsubscribe send a blank email to > xxxxx@lists.osr.com > > > > > > > > — > Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You must also recalculate the TCP or UDP checksum and not only IP. Some
fields of the IP header are included to these checksums. Addresses are among
them.
BTW - IP packets have no ports, only TCP or UDP have.
----- Original Message -----
From: “Xia Tao” To: “Windows System Software Devs Interest List” Sent: Thursday, March 18, 2004 12:55 PM Subject: [ntdev] No ACK in NDIS IM Forwarding
> I am writing a NDIS IM software. The goal is to change the destination IP > address and port of the IP packet. For example, the original IP packet is > destinated to the 192.168.1.1:22, I want to change the destination > IP:port(192.168.1.1:22) to 192.168.1.2:22. > > What do I do in the NDIS IM part: > (1) In the NDIS packet, change the detination IP from the original > 192.168.1.1 to 192.168.1.2 > (2) re-calculate the IP checksum > Then send the changed NDIS packet out. > Now the 192.168.1.2 can get the packet I send. But there is no ACK packet > back from the 192.168.1.2. > What’s wrong with my process? Help please. Thanks in advance. > > Here is the output of the tcpdump, > 19:59:38.517324 192.168.1.5.1803 > 192.168.1.2.ssh: S > 2425191351:2425191351(0) win 64240 (DF) > 19:59:41.462994 192.168.1.5.1803 > 192.168.1.2.ssh: S > 2425191351:2425191351(0) win 64240 (DF) > 19:59:47.498883 192.168.1.5.1803 > 192.168.1.2.ssh: S > 2425191351:2425191351(0) win 64240 (DF) > > > > — > Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256 > > You are currently subscribed to ntdev as: xxxxx@storagecraft.com > To unsubscribe send a blank email to xxxxx@lists.osr.com
From RFC 793, on how the TCP checksum is calculated:
The checksum also covers a 96 bit pseudo header conceptually
[Page 16]
September 1981
Transmission Control Protocol
Functional Specification
prefixed to the TCP header. This pseudo header contains the Source
Address, the Destination Address, the Protocol, and TCP length.
This gives the TCP protection against misrouted segments. This
information is carried in the Internet Protocol and is transferred
across the TCP/Network interface in the arguments or results of
calls by the TCP on the IP.
The TCP Length is the TCP header length plus the data length in
octets (this is not an explicitly transmitted quantity, but is
computed), and it does not count the 12 octets of the pseudo
header.
Of course you are wrong, As we know, the tcp header checksum must include
a pseudo header which contains src ip/dest ip / tcp len. So, when change
your ip address, you have to recalculate the checksum of tcp header.
----- Original Message ----- From: “Maxim S. Shatskih” To: “Windows System Software Devs Interest List” Sent: Thursday, March 18, 2004 8:21 PM Subject: Re: [ntdev] No ACK in NDIS IM Forwarding
> You must also recalculate the TCP or UDP checksum and not only IP. Some > fields of the IP header are included to these checksums. Addresses are among > them. > > BTW - IP packets have no ports, only TCP or UDP have. > > Maxim Shatskih, Windows DDK MVP > StorageCraft Corporation > xxxxx@storagecraft.com > http://www.storagecraft.com > > > ----- Original Message ----- > From: “Xia Tao” > To: “Windows System Software Devs Interest List” > Sent: Thursday, March 18, 2004 12:55 PM > Subject: [ntdev] No ACK in NDIS IM Forwarding > > > > I am writing a NDIS IM software. The goal is to change the destination IP > > address and port of the IP packet. For example, the original IP packet is > > destinated to the 192.168.1.1:22, I want to change the destination > > IP:port(192.168.1.1:22) to 192.168.1.2:22. > > > > What do I do in the NDIS IM part: > > (1) In the NDIS packet, change the detination IP from the original > > 192.168.1.1 to 192.168.1.2 > > (2) re-calculate the IP checksum > > Then send the changed NDIS packet out. > > Now the 192.168.1.2 can get the packet I send. But there is no ACK packet > > back from the 192.168.1.2. > > What’s wrong with my process? Help please. Thanks in advance. > > > > Here is the output of the tcpdump, > > 19:59:38.517324 192.168.1.5.1803 > 192.168.1.2.ssh: S > > 2425191351:2425191351(0) win 64240 (DF) > > 19:59:41.462994 192.168.1.5.1803 > 192.168.1.2.ssh: S > > 2425191351:2425191351(0) win 64240 (DF) > > 19:59:47.498883 192.168.1.5.1803 > 192.168.1.2.ssh: S > > 2425191351:2425191351(0) win 64240 (DF) > > > > > > > > — > > Questions? First check the Kernel Driver FAQ at > http://www.osronline.com/article.cfm?id=256 > > > > You are currently subscribed to ntdev as: xxxxx@storagecraft.com > > To unsubscribe send a blank email to xxxxx@lists.osr.com > > > — > Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256 > > You are currently subscribed to ntdev as: xxxxx@wtwh.com.cn > To unsubscribe send a blank email to xxxxx@lists.osr.com > >
Client connected to Proxy which the Src/Dest IP of SYN packet was
192.168.1.5/192.168.1.2, and When Proxy received this packet your kernel
mode driver should modify this pair of ip address to
192.168.1.2/192.168.1.1 and then send it to the Server (192.168.1.1).
But packets you dump shown only the destination ip was modified to
192.168.1.1, while the source ip remains unchanged.
So, The Server received a SYN Pakcet which the Src/Dest IP is
192.168.1.5/192.168.1.1, then the server response a SYN/ACK packet
direct to the Client. When this SYN/ACK packet arrived at Client, The
client tcp/ip protocol stack found there was nerver a SYN request sent
to 192.168.1.1, so it response a RST packet to the server.
Maybe I didnt express the idea cleanly. The idea here is you should
modify the Src ip also but not only the destination ip. So when Server
received the modified SYN request packet, it will response a SYN/ACK
packet to your Proxy and then your kernel mode driver running at the
Proxy should also modified the source and destination ip of this SYN/ACK
packet and send it back to then Client.
Dont forget to recalculate the checksum of ip and tcp header.
Hi. Sorry I do not get my case clear.
My topology is simple as following:
Test PC(192.168.1.1, my NDIS IM software on it) <---------------------> SSH
Server (192.168.1.5)
What I want to do, when 192.168.1.1 connects to the 192.168.1.2, the NDIS IM
interpt the packet and modify the destination IP from 192.168.1.2 to
192.168.1.5 in the test PC. Then sends out the packet.
What I have done in the NDIS IM when sending out the packet:
(1) modify the destination IP from 192.168.1.2 to 192.168.1.5
(2) recalculate the IP header checksum
(3) recalculate the TCP header checksum
Now 1. 192.168.1.1 ---->192.168.1.5 SYN okay
2. 192.168.1.5 ----> 192.168.1.1 ACK okay
3. 192.168.1.5 ---->192.168.1.1 RST, (should be ACK if normal)
Do I need to change anything in receiving packet?
----- Original Message -----
From: “sevenyears” To: “Windows System Software Devs Interest List” Sent: Friday, March 19, 2004 3:13 PM Subject: Re: [ntdev] No ACK in NDIS IM Forwarding
> Well, I guess the topology of your testing platform as following: > > Client(192.168.1.5)<---->Proxy(192.168.1.2)<---->Server(192.168.1.1) > > Client connected to Proxy which the Src/Dest IP of SYN packet was > 192.168.1.5/192.168.1.2, and When Proxy received this packet your kernel > mode driver should modify this pair of ip address to > 192.168.1.2/192.168.1.1 and then send it to the Server (192.168.1.1). > But packets you dump shown only the destination ip was modified to > 192.168.1.1, while the source ip remains unchanged. > > So, The Server received a SYN Pakcet which the Src/Dest IP is > 192.168.1.5/192.168.1.1, then the server response a SYN/ACK packet > direct to the Client. When this SYN/ACK packet arrived at Client, The > client tcp/ip protocol stack found there was nerver a SYN request sent > to 192.168.1.1, so it response a RST packet to the server. > > Maybe I didnt express the idea cleanly. The idea here is you should > modify the Src ip also but not only the destination ip. So when Server > received the modified SYN request packet, it will response a SYN/ACK > packet to your Proxy and then your kernel mode driver running at the > Proxy should also modified the source and destination ip of this SYN/ACK > packet and send it back to then Client. > > Dont forget to recalculate the checksum of ip and tcp header. > > > > > > — > Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256 > > You are currently subscribed to ntdev as: xxxxx@wtwh.com.cn > To unsubscribe send a blank email to xxxxx@lists.osr.com > >
10:40:14.639358 192.168.1.1.ssh > 192.168.1.5.1664: S
2757802783:2757802783(0) ack 3260414033 win 5840 3) 10:40:14.639486 192.168.1.5.1664 > 192.168.1.1.ssh: R 3260414033:3260414033(0) win 0
You said: > Now 1. 192.168.1.1 ---->192.168.1.5 SYN okay > 2. 192.168.1.5 ----> 192.168.1.1 ACK okay > 3. 192.168.1.5 ---->192.168.1.1 RST, (should be ACK if normal) Not the same, well, this is not important.
the 2nd you said should be 192.168.1.5---->192.168.1.1 syn/ack okay. When this syn/ack packet returns to your testpc(192.168.1.1), your im driver should modify the source ip to 192.168.1.2. If you remains it unchanged, the tcp/ip stack of operating system will response a rst packet to 192.168.1.5 because there are not a syn request to 192.168.1.5 in the upper layer protocol(Remember your application connects to 192.168.1.2!). So the 3rd should be 192.168.1.1---->192.168.1.5 rst packet.
Hi??sevenyears
I am doing the same testing, and I joined the mail list just now.
I am strange about the recieve package. I add the routine to deal with
the package from 192.168.1.5.
I do the testing based on the code “http://www.wd-3.com/121503/ExtendingPassThru2.htm”.
I preserve the routine of the FltFilterReceivePacket and FltFilterReceive function, just comment:
modify the FltFilterSendPacket function, add the replace the orig ip, check ip sum and check tcp sum code.
add the code to deal with the recieve package on the PtReceivePacket and PtReceive.
In detail, PtReceivePacket register with ReceivePacketHandler,
and PtReceive regiester with ReceiveHandler.
in the PtReceive and PtReceivePacket routine:
ModifyRecv(MyPacket); //my code to deal the recieve package ip, ipchecksum, tcpchecksum
NdisMIndicateReceivePacket(pAdapt->MiniportHandle, &MyPacket, 1);
But I can not get tcp package.
FltReadOnPacket(
Packet,
package,
1514, //ETH_HEADER_SIZE + ETH_MAX_DATA_SIZE
0,
&realNum
);
pether = (struct ether_header *)package;
if( RtlUshortByteSwap( pether->ether_type ) != ETHERTYPE_IP)
return;
pheader = (struct ip *)(package + sizeof(struct ether_header));
if(pheader->ip_v != 4)
return;
DbgPrint(“RECV pheader->ip_p 0x\n”, pheader->ip_p);
if( pheader->ip_p != IPPROTO_TCP)
return;
…
I can only see the ip_p is 0x11(UDP), I can get TCP package, why?
Best Regards
Ouyang Kai
As your dump shown:
192.168.1.5.1664 > 192.168.1.1.ssh: S
10:40:14.639358 192.168.1.1.ssh > 192.168.1.5.1664: S
2757802783:2757802783(0) ack 3260414033 win 5840 >3) 10:40:14.639486 192.168.1.5.1664 > 192.168.1.1.ssh: R >3260414033:3260414033(0) win 0 > >You said: >> Now 1. 192.168.1.1 ---->192.168.1.5 SYN okay >> 2. 192.168.1.5 ----> 192.168.1.1 ACK okay >> 3. 192.168.1.5 ---->192.168.1.1 RST, (should be ACK if normal) >Not the same, well, this is not important. > >the 2nd you said should be 192.168.1.5---->192.168.1.1 syn/ack okay. >When this syn/ack packet returns to your testpc(192.168.1.1), your im >driver should modify the source ip to 192.168.1.2. If you remains it >unchanged, the tcp/ip stack of operating system will response a rst >packet to 192.168.1.5 because there are not a syn request to 192.168.1.5 >in the upper layer protocol(Remember your application connects to >192.168.1.2!). So the 3rd should be 192.168.1.1---->192.168.1.5 rst >packet. > > > >— >Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256 > >You are currently subscribed to ntdev as: xxxxx@wtwh.com.cn >To unsubscribe send a blank email to xxxxx@lists.osr.com > >. Best Regards Ouyang Kai
Hi??sevenyears
My testing is :
my xp box(10.1.1.176) - 10.1.0.159/10.1.0.158
10.1.0.158 and 10.1.0.159 are the two ip on the same linux box.
I connect to 10.1.0.159, and redirect to 10.1.0.158 in NDIS-IM.
Case2 Now, I comment the ModifyRecv, and in the FltFilterReceivePacket function, I add the ModifyRecv, it could recieve tcp package. 11:41:51.749986 10.1.1.176.4594 > 10.1.0.158.ssh: S 2789437361:2789437361(0) win 64240 (DF) 4500 0030 8410 4000 8006 6068 0a01 01b0 0a01 009e 11f2 0016 a643 6fb1 0000 0000 7002 faf0 49e2 0000 0204 05b4 0101 0402 11:41:51.750057 10.1.0.158.ssh > 10.1.1.176.4594: S 3741056973:3741056973(0) ack 2789437362 win 5840 (DF) 4500 0030 0000 4000 4006 2479 0a01 009e 0a01 01b0 0016 11f2 defb ffcd a643 6fb2 7012 16d0 4f28 0000 0204 05b4 0101 0402 11:41:51.750293 10.1.1.176.4594 > 10.1.0.158.ssh: . ack 1 win 64240 (DF) 4500 0028 8411 4000 8006 606f 0a01 01b0 0a01 009e 11f2 0016 a643 6fb2 defb ffce 5010 faf0 97cb 0000 0000 0000 0000 11:41:51.752076 10.1.0.158.ssh > 10.1.1.176.4594: P 1:26(25) ack 1 win 5840 (DF) 4500 0041 0d4f 4000 4006 1719 0a01 009e 0a01 01b0 0016 11f2 defb ffce a643 6fb2 5018 16d0 e0c4 0000 5353 482d 312e 3939 2d4f 7065 6e53 5348 5f33 2e37 2e31 7032 0a 11:41:54.750031 10.1.0.158.ssh > 10.1.1.176.4594: P 1:26(25) ack 1 win 5840 (DF) 4500 0041 0d50 4000 4006 1718 0a01 009e 0a01 01b0 0016 11f2 defb ffce a643 6fb2 5018 16d0 e0c4 0000 5353 482d 312e 3939 2d4f 7065 6e53 5348 5f33 2e37 2e31 7032 0a … It seems successful… but I do not know why. About NDIS-IM, where should i deal with the recieved package, do i need to distinguish the udp and tcp package? BTW, In Case2, I do not know why I test failure yesterday, the same code as today testing.
Best Regards Ouyang Kai >Do you have ever used a sniffer to dump the packets in the testing ? > > >— >Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256 > >You are currently subscribed to ntdev as: xxxxx@wtwh.com.cn >To unsubscribe send a blank email to xxxxx@lists.osr.com > >.
I havent seen the code in http://www.wd-3.com/121503/ExtendingPassThru2.htm
and dont exactly known how you have modified the code.
But As I known, you have to modified the received packet in both
PtReceive and PtReceivePacket in your im driver, and in PtReceive the
processing is more complicate.
At almost all cases, you need to distinguish the udp and tcp according
to the protocol and the application.
This is not a quite difficult task, good luck to you!
Thanks for your help. Now our problem is solved. We can redirect a
connection by the NDIS IM.
I have another question: for the IP:port redirection, the NDIS IM need to
handle the sending and receiving packets. We could also use the TDI filter
to implement this feature. Which one will have better performance: NDIS IM
or TDI filter? As far as I know, it seems that the TDI filter should have
better performance since TDI only need to handle per connection.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of sevenyears
Sent: 2004??3??20?? 18:11
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] No ACK in NDIS IM Forwarding
I havent seen the code in http://www.wd-3.com/121503/ExtendingPassThru2.htm
and dont exactly known how you have modified the code.
But As I known, you have to modified the received packet in both
PtReceive and PtReceivePacket in your im driver, and in PtReceive the
processing is more complicate.
At almost all cases, you need to distinguish the udp and tcp according
to the protocol and the application.
This is not a quite difficult task, good luck to you!
I have no experienced about Ip:port redirection in TDI filter driver.
But as I known, in TDI Filter driver to access the packet data is quite
complicate. Do it in IM driver is simpler as far as I experienced. And
I think im driver implementation is more efficient.
> handle the sending and receiving packets. We could also use the
TDI filter
to implement this feature. Which one will have better
performance: NDIS IM
or TDI filter? As far as I know, it seems that the TDI filter
TDI filters are not supported and not recommended by Microsoft.
It is enough for me to prefer NDIS IM in the vast majority of cases, with the
only exception of mapping ports to PIDs and EXE file names (impossible in
NDIS).