This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

How can I replay a tcp packet captured by wireshark?

0

Hello everyone, I captured a tcp traffic using wireshark and saved the traffic in pcap file. I did two tests:

Test 1:
#tcprewrite --infile=capturedtraffic.pcap --outfile=temp.pcap --srcipmap=0.0.0.0/0:192.168.1.15 --enet-smac=00:0c:29:de:78:42
#tcpreplay --intf1=eth0 temp.pcap

Test 2:


tcpliveplay eth0 capturedtraffic.pcap 192.168.1.13 00:24:21:1e:29:b2 random

For both tests, the TCP replay didn’t work. I’m getting RST. I didn’t find also a traffic comming to my TCP server application. Do you have any ideas on how to resolve this problems?

The captured data:

alt text

The test results:

alt text

alt text

Note that I used Kali Linux. Thanks in advance. Jack

asked 05 Jan ‘16, 07:42

jackABA's gravatar image

jackABA

6●1●1●4
accept rate: 0%

edited 06 Jan ‘16, 02:13

Seems to me this is a tcpreplay issue not Wireshark. You’ll probably find more helpful support on the tcpreplay-users mailing list as suggested by the tcpreplay support page.

(06 Jan ‘16, 02:50) grahamb ♦

One Answer:

1

tcpliveplay description says that it modifies the captured data, while sending them, in such a way that as much as possible of the original packets would be preserved but the tcp session would establish properly, i.e. the SEQ and ACK numbers are not replayed from the stored version but modified to match the initial values of the new session.

So little can be said until you make clear at what phase the server sends the RST. After receiving SYN? After receiving the first "real" packet after the initial handshake (SYN, SYN+ACK, ACK)?

Both the original capture (which you are attempting to replay) and the capture of the replay attempt would be the best input data for any further analysis.

If I've understood you right and the machine which is running the tcpliveplay is getting RST whereas the server has not received even the SYN packet, there is a firewall somewhere on the way between the two machines which prevents the SYN packet from being delivered and itself responds to it with RST.

Or you may have missed this part of the manual:

Due to the nature of the replay, you must suppress the kernel RST flags because the replay is injecting packets into the replay station’s NIC. Issue the following:

# sudo iptables -A OUTPUT -p tcp --tcp-flags RST RST -s <your ip> -d <dst ip> --dport <dst port, example 80 or 23 etc.> -j DROP

Example of suppress command:

# sudo iptables -A OUTPUT -p tcp --tcp-flags RST RST -s 10.0.2.15 -d 192.168.1.10 --dport 80 -j DROP

answered 05 Jan '16, 15:16

sindy's gravatar image

sindy
6.0k●4●8●51
accept rate: 24%

edited 05 Jan '16, 15:20

Thanks for quick replay. we have already used the iptables command. but we have the same issue. we are getting RST. I added some screenshots that describe the issue.

(06 Jan '16, 02:15) jackABA

I agree with @grahamb, but add some more remarks... tcpliveplay says, at the page I've linked in my answer, that the capture to be replayed must contain just a single tcp session.

The Wireshark packet list you've pasted from the original capture shows two distinct sessions (packets 1-7 and 8-last), each from a different port at client side. It is possible that this confuses tcpliveplay already before it reaches the end of the first session while sending.

So you have to use Wireshark filters and File -> Save As to extract the individual session(s) into individual pcap file(s), and then replay it (them) individually.

The capture from the replay shows that tcpliveplay has sent the SYN packet, the intended server (or something else) has responded by a SYN,ACK packet, but tcpliveplay has never sent the ACK to that one itself, which made the server make two retransmit attempts for the SYN, ACK, and only after still getting no response, send the RST.

(06 Jan '16, 03:15) sindy