Drop TCP packets and prevent TCP retransmission

Question

I have an application that sends TCP data to a server. My server is made to intentionally drop the packets sent by the application, and as a result the client retransmits the packets. I need to prevent the client from retransmitting them. Is there any setting that I can do on the client to prevent retransmits. Maybe some iptables rule? Or with some net.ipv4.tcp variables?

I understand that TCP inherently has to retransmit packets, but I actually need to test out a functionality on my server, where I have to observe how the server behaves when it drops a TCP packet and it does not get retransmitted. So I cannot use UDP here.

The client is able to complete the TCP handshake, and only the packets sent after that are dropped, for which the retransmission is happening. This is the retransmission that I need to prevent.

I am using Fedora :

[root@test sipp.svn]# uname -r
2.6.23.1-42.fc8
[root@test sipp.svn]# 

Answer 1

From your comment (which would better be part of your question):

I understand that TCP inherently has to retransmit packets, but I actually need to test out a functionality on my server, where I have to observe how the server behaves when it drops a TCP packet and it does not get retransmitted. So I cannot use UDP here.

From my understanding you don't need to actually care what the client sends, it is only important that the resubmitted packets don't arrive at the server. So why don't you drop these packets at the server side the same way you dropped the initial packet? I don't know how you dropped this, but with iptables it should probably be enough to block any TCP packets without SYN/FIN from the client.

If you instead need to make the client don't care you would need to fake the ACKs from the server. You might do such things with scapy or similar tools.

Answer 2

Removing my comment and posting an answer instead.

TCP was designed for reliability and error-checked transmissions. For this reason, it is in its very nature to resend packets which were not ACK-nowledged by the other end of the connection. If you don't want this mechanism to apply, you should probably just use another protocol such as UDP.

However, if you're stuck with TCP, you might want to use a proxy application. Instead of receiving the TCP packets directly on your application on the server side, have them received by another application, a proxy, which will decide whether or not transmit the packets to the "real" application behind. Basically:

• The client sends its TCP packets.
• A proxy application on the server-side receives them on port A.
• Your real server application listens on port B.
• The proxy application decides whether or not to transmit a packet from A to B.

Since the proxy always acknowledges the packets, they are never retransmitted (except if they actually fail to get there of course). With this in mind, it is up to you to use/design a proxy application which applies the proper filtering rules. Here is a link to a related question I asked on Security Stack Exchange.