replayed wireshark recorded tcp packets fail to establish 3 steps handshake with tcp listener

Question

I have a wireshark recorded pcap file, I use bittwist/bittwiste (http://bittwist.sourceforge.net/doc.html) to alter MAC Addr, IP, TCP ports of source/destination in that pcap, the server under test is a c# tcplistener, client is the replayed packets of that pcap file by bittwist, but the 3 step handshake is never successful, what happens is the following:

Client >> SYN

SYN/ACK << Server

Client >> RST (with a seq number=1 but ack number is a huge number)

Instead of what should happen:

Client >> SYN

SYN/ACK << Server

Client >> ACK

It seems to me that the client decides to close the connection, but the client in my case is the replayed packets, which simply does the following in the first 2 packets:

Client >> SYN

Client >> ACK

so the question is why the third step is RST instead of ACK based on the pcap file?

Answer 1

Most likely, the native TCP stack on your client machine received the server SYN/ACK and, since it was not trying to connect to the server, it sent the RST.

Just because you have an app using the interface in promiscuous mode does not prevent the native TCP/IP stack from also receiving packets.

You need to disable TCP/IP on the interface you are using. The question of how depends on the OS your client is using.

Alternatively, you need a way to filter out packets from the server from reaching the native TCP stack. Again, this depends, if even possible, on the OS.