tcpreplay not work client not receive the data

Question

In server

# nc -lp 2424
hi server
hi client
1
2
3

In client

➜  ~ nc 139.224.xxx.xx 2424
hi server
hi client
1
2
3

Then in client

➜  ~ sudo tcpdump -i en0 -nn -s0 -v src port 2424 -c 10 -w 2424.pcap
tcpdump: listening on en0, link-type EN10MB (Ethernet), capture size 262144 bytes
10 packets captured
93 packets received by filter
0 packets dropped by kernel

➜  ~ tcpdump -r 2424.pcap
reading from file 2424.pcap, link-type EN10MB (Ethernet)
16:49:47.874743 IP 139.224.xxx.xx.kofax-svr > 192.168.199.171.53511: Flags [P.], seq 2832846522:2832846524, ack 587632101, win 227, options [nop,nop,TS val 1632491736 ecr 751973860], length 2
16:49:48.795743 IP 139.224.xxx.xx.kofax-svr > 192.168.199.171.53511: Flags [P.], seq 2:4, ack 1, win 227, options [nop,nop,TS val 1632492657 ecr 752338627], length 2
16:49:49.786093 IP 139.224.xxx.xx.kofax-svr > 192.168.199.171.53511: Flags [P.], seq 4:6, ack 1, win 227, options [nop,nop,TS val 1632493648 ecr 752339543], length 2

but when I replay it the client nc console nothing output

➜  ~ tcpreplay -ien0 2424.pcap
Warning: May need to run as root to get access to all network interfaces.
Actual: 10 packets (681 bytes) sent in 10.84 seconds
Rated: 62.7 Bps, 0.000 Mbps, 0.92 pps
Statistics for network device: en0
    Successful packets:        10
    Failed packets:            0
    Truncated packets:         0
    Retried packets (ENOBUFS): 0
    Retried packets (EAGAIN):  0

What's the reason? I think execute the tcpreplay just like send data from the server. So what is the difference between send data in server nc console with tcpreplay in client?

Answer 1

The reason is simple; you cannot replay packets using tcpreplay and expect the client (or the server) to see the data as part of the connection.

There are many reasons for this. Here are just three.

1) When the client connects to the server, it selects an (effectively random, though likely just incremented) ephemeral port as the source. The replayed data will contain the port from the original connection, which is almost certainly not going to be the same as the client is using now.

2) When a connection is established, the client and server each establish a random initial sequence number for its connection to the other. This number is even less likely to be the same in the new connection.

3) When the client sends the SYN to the server, even though you are replaying data, the server will send back a RST ACK, shutting down the connection (regardless of the replayed packets) because the listener is no longer available.