Thanks for outlining the problem.

I'm labeling this as a bug for now, but will not assign to myself. Tcpliveplay was developed through a Cisco project before I was involved in Tcpreplay. I'll see if I can find the original author and see if he is interested in maintaining this code.

If not, I'll either have to dive into it myself, get another volunteer to step in or make some drastic decisions about the future of Tcpliveplay.

Thanks a lot for the quick replay.
Do you another way or tool that I could accomplish the same goal as tcpliveplay?

I would suggest trying tcpliveplay version 3.4.4. I think that was the last version touched only be original developer. Mainly security fixes have gone in since then. If it does work for you, let me know and I can do git bisect to isolate the failing commit.

Thanks! I'll check and let you know.

The Ubuntu tcpreplay package version 3.4.4-2+deb8u1build0.16.04.1 doesn't have the tcpliveplay file.
Are you sure this is the right version?

# apt show tcpreplay
Package: tcpreplay
Version: 3.4.4-2+deb8u1build0.16.04.1
Priority: optional
Section: universe/net
Origin: Ubuntu
Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
Original-Maintainer: Noël Köthe <noel@debian.org>
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Installed-Size: 1,032 kB
Depends: libc6 (>= 2.14), libpcap0.8 (>= 0.9.8)
Homepage: http://tcpreplay.synfin.net/
Download-Size: 198 kB
APT-Manual-Installed: yes
APT-Sources: http://us.archive.ubuntu.com/ubuntu xenial-updates/universe amd64 Packages
Description: Tool to replay saved tcpdump files at arbitrary speeds
 Tcpreplay is aimed at testing the performance of a NIDS by
 replaying real background network traffic in which to hide
 attacks. Tcpreplay allows you to control the speed at which the
 traffic is replayed, and can replay arbitrary tcpdump traces. Unlike
 programmatically-generated artificial traffic which doesn't
 exercise the application/protocol inspection that a NIDS performs,
 and doesn't reproduce the real-world anomalies that appear on
 production networks (asymmetric routes, traffic bursts/lulls,
 fragmentation, retransmissions, etc.), tcpreplay allows for exact
 replication of real traffic seen on real networks.

N: There is 1 additional record. Please use the '-a' switch to see it
# dpkg-query -L tcpreplay
/.
/usr
/usr/bin
/usr/bin/tcprewrite
/usr/bin/tcpreplay-edit
/usr/bin/tcpprep
/usr/bin/tcpreplay
/usr/bin/tcpbridge
/usr/share
/usr/share/doc
/usr/share/doc/tcpreplay
/usr/share/doc/tcpreplay/copyright
/usr/share/doc/tcpreplay/changelog.Debian.gz
/usr/share/doc/tcpreplay/TODO.gz
/usr/share/man
/usr/share/man/man1
/usr/share/man/man1/tcprewrite.1.gz
/usr/share/man/man1/tcpreplay-edit.1.gz
/usr/share/man/man1/tcpprep.1.gz
/usr/share/man/man1/tcpbridge.1.gz
/usr/share/man/man1/tcpreplay.1.gz

@riramar my mistake. I started maintaining (and now own) 4.0.0 and didn't realize that tcpliveplay was not distributed with 3.4.4. I am now the lone maintainer of Tcpreplay and don't know the entire history of Tcpliveplay. I'll ask the previous maintainers what version it was supported.

I suspect support was dropped before 3.4.4, but the source code was not in the release tarballs. I may have to drop it as well, unless I can fix this bug.

Sorry, I don't know of an alternative. I think I saw something once in GitHub, but I cannot remember where.

No problem @fklassen ... I really appreciate your quick replies.

I am having the exact same issue on Kali with this version:

tcpliveplay version: 4.3.2 (build git:v4.3.2) (debug)
Copyright 2012 by Yazan Siam <tcpliveplay@gmail.com>
Not compiled with libdnet.
Compiled against libpcap: 1.9.1
64 bit packet counters: enabled
Verbose printing via tcpdump: enabled
Injection method: PF_PACKET send()

Is there any news to this topic? @riramar did you solve the situation for yourself?

Thanks a bunch!

I have just downloaded and built the latest version from github and fail also with the other available injection methods:

tcpliveplay version: 4.3.2 (build git:v4.3.2)
Copyright 2012 by Yazan Siam <tcpliveplay@gmail.com>
Not compiled with libdnet.
Compiled against libpcap: 1.9.1
64 bit packet counters: enabled
Verbose printing via tcpdump: enabled
Injection method: pcap_sendpacket()

and

tcpliveplay version: 4.3.2 (build git:v4.3.2)
Copyright 2012 by Yazan Siam <tcpliveplay@gmail.com>
Not compiled with libdnet.
Compiled against libpcap: 1.9.1
64 bit packet counters: enabled
Verbose printing via tcpdump: enabled
Injection method: pcap_inject()

Here is the output of one run:

root@kali:~/Downloads/tcpreplay-4.3.2# src/tcpliveplay eth0 ~/service-connection.pcap 192.168.0.5 re:dac:ted:6C:CB:BB random
new source port:: 59506
Random Local SEQ: 140580199
Packets Scheduled 241
Sending Local Packet...............     [1]
Receiving Packets from remote host...
Received Remote Packet...............   [2]
Remote Pakcet Expectation met.
Proceeding in replay....

======================================================================
= TIMEOUT:: Remote host is not responding. You may have crashed      =
= the host you replayed these packets against OR the packet sequence =
= changed since the capture was taken resulting in differing         =
= expectations. Closing replay...                                    =
======================================================================

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ Unfortunately an error has occurred  halting the replay of
~ the pcap file '/root/service-connection.pcap'. Please see error above for details...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

----------------TCP Live Play Summary----------------
- Packets Scheduled to be Sent & Received:          241
- Actual Packets Sent & Received:                   2
- Total Local Packet Re-Transmissions due to packet
- loss and/or differing payload size than expected: 0
- Thank you for Playing, Play again!
----------------------------------------------------------

What I can see in a parallel wireshark session is, that my machine is sending out a TCP SYN packet and the server is responding with a SYN ACK. No ACK is given by my machine. After a few seconds, the server resends the SYN ACK a couple of times. Finally the program aborts, claiming that the server did not respond. Opening a TCP session with telnet to the same port works just fine. There are no iptables rules, except for the one suppressing the RST from the kernel, as per tcpliveplay documentation. Kernel version is 5.4.0-kali2-amd64.

I discussed with an early maintainer, and unless we find a volunteer to take on tcpliveplay, we will drop support in version 4.4.