Specify a list of comma delimited port mappings consisting of colon delimited port number pairs. Each colon delimited port pair consists of the port to match followed by the port number to rewrite.

Examples:

    --portmap=80:8000 --portmap=8080:80    # 80->8000 and 8080->80
    --portmap=8000,8080,88888:80           # 3 different ports become 80
    --portmap=8000-8999:80                 # ports 8000 to 8999 become 80
    

Causes the source and destination IPv4/v6 addresses to be pseudo randomized but still maintain client/server relationships. Since the randomization is deterministic based on the seed, you can reuse the same seed value to recreate the traffic.

Takes a comma delimited series of colon delimited CIDR netblock pairs. Each netblock pair is evaluated in order against the IP addresses. If the IP address in the packet matches the first netblock, it is rewritten using the second netblock as a mask against the high order bits.

IPv4 Example:

    --pnat=192.168.0.0/16:10.77.0.0/16,172.16.0.0/12:10.1.0.0/24
    

    --pnat=[2001:db8::/32]:[dead::/16],[2001:db8::/32]:[::ffff:0:0/96]
    

Works just like the --pnat option, but only affects the source IP addresses in the IPv4/v6 header.

Works just like the --pnat option, but only affects the destination IP addresses in the IPv4/v6 header.

Takes a pair of colon delimited IPv4/v6 addresses which will be used to rewrite all traffic to appear to be between the two IP addresses.

IPv4 Example:

    --endpoints=172.16.0.1:172.16.0.2
    

    --endpoints=[2001:db8::dead:beef]:[::ffff:0:0:ac:f:0:2]
    

greater than or equal to 1
    

Change all TCP sequence numbers, and related sequence-acknowledgement numbers. They will be shifted by a random amount based on the provided seed.

By default --seed, --pnat and --endpoints will rewrite broadcast and multicast IPv4/v6 and MAC addresses. Setting this flag will keep broadcast/multicast IPv4/v6 and MAC addresses from being rewritten.

Causes each IPv4/v6 packet to have their checksums recalculated and fixed. Automatically enabled for packets modified with --seed, --pnat, --endpoints or --fixlen.

in the range  1 through MAX_SNAPLEN
    

Override the default 1500 byte MTU size for determining the maximum padding length (--fixlen=pad) or when truncating (--mtu-trunc).

Similar to --fixlen, this option will truncate data in packets from Layer 3 and above to be no larger then the MTU.

Note, this option is pretty dangerous! We do not actually check to see if a FCS actually exists in the frame, we just blindly delete the last 4 bytes. Hence, you should only use this if you know know that your OS provides the FCS when reading raw packets.

Allows you to modify the TTL/Hop Limit of all the IPv4/v6 packets. Specify a number to hard-code the value or +/-value to increase or decrease by the value provided (limited to 1-255).

Examples:

    --ttl=10
    --ttl=+7
    --ttl=-64
    

in the range  0 through 255
    

Allows you to override the TOS (also known as DiffServ/ECN) value in IPv4.

in the range  0 through 255
    

Allows you to override the IPv6 Traffic Class field.

in the range  0 through 1048575
    

Allows you to override the 20bit IPv6 Flow Label field. Has no effect on IPv4 packets.

Packets may be truncated during capture if the snaplen is smaller then the packet. This option allows you to modify the packet to pad the packet back out to the size stored in the IPv4/v6 header or rewrite the IP header total length to reflect the stored packet length.

pad Truncated packets will be padded out so that the packet length matches the IPv4 total length

trunc Truncated packets will have their IPv4 total length field rewritten to match the actual packet length

del Delete the packet

greater than or equal to 0
    

This fuzzing was designed as to test layer 7 protocols such as voip protocols. It modifies randomly 1 out of X packets (where X = --fuzz-factor) in order for stateful protocols to cover more of their code. The random fuzzing actions focus on data start and end because it often is the part of the data application protocols base their decisions on.

Possible fuzzing actions list: * drop packet * reduce packet size * edit packet Bytes: * Not all Bytes have the same probability of appearance in real life. Replace with 0x00, 0xFF, or a random byte with equal likelihood. * Not all Bytes have the same significance in a packet. Replace the start, the end, or the middle of the packet with equal likelihood. * do nothing (7 out of 8 packets)

greater than or equal to 1
    

Sets the ratio of for --fuzz-seed option. By default this value is 8, which means 1 in 8 packets are modified by fuzzing. Note that this ratio is based on the random number generated by the supplied fuzz seed. Therefore by default you cannot expect that exactly every eighth packet will be modified.

By default, editing Layer 2 addresses will rewrite broadcast and multicast MAC addresses. Setting this flag will keep broadcast/multicast MAC addresses from being rewritten.

By default, no DLT (data link type) conversion will be made. To change the DLT type of the output pcap, select one of the following values:

enet Ethernet aka DLT_EN10MB

hdlc Cisco HDLC aka DLT_C_HDLC

jnpr_eth Juniper Ethernet DLT_C_JNPR_ETHER

pppserial PPP Serial aka DLT_PPP_SERIAL

user User specified Layer 2 header and DLT type

Takes a pair of comma deliminated ethernet MAC addresses which will replace the destination MAC address of outbound packets. The first MAC address will be used for the server to client traffic and the optional second MAC address will be used for the client to server traffic.

Example:

    --enet-dmac=00:12:13:14:15:16,00:22:33:44:55:66
    

Takes a pair of comma deliminated ethernet MAC addresses which will replace the source MAC address of outbound packets. The first MAC address will be used for the server to client traffic and the optional second MAC address will be used for the client to server traffic.

Example:

    --enet-smac=00:12:13:14:15:16,00:22:33:44:55:66
    

Allows you to rewrite ethernet MAC addresses of packets. It takes comma delimited pair or MACs address and rewrites all occurrences of the first MAC with the value of the second MAC. Example:

    --enet-subsmac=00:12:13:14:15:16,00:22:33:44:55:66
    

Allows you to randomize ethernet MAC addresses of packets, mostly like what --seed option does for IPv4/IPv6 addresses.

in the range  1 through 6
    

Keep some bytes untouched when usinging --enet-mac-seed option.

Allows you to rewrite ethernet frames to add a 802.1q header to standard 802.3 ethernet headers or remove the 802.1q VLAN tag information.

add Adds an 802.1q VLAN header to the existing 802.3 ethernet header. If a VLAN header already exists, a new VLAN header is added outside of the existing header.

Note that you will be allowed to run this option multiple times to create more than 2 VLAN headers, however those packets will be valid. At most you should have 2 X 802.1q VLAN tags, or outer an 802.1ad and an inner 802.1q VLAN tag.

del Rewrites the existing 802.1q VLAN header as an 802.3 ethernet header

in the range  0 through 4095
    

in the range  0 through 1
    

in the range  0 through 7
    

Allows you to specify the protocol of the added VLAN tags.

802.1q Specifies that 802.1q VLAN headers are to be added. This is the default.

802.1ad Specifies that 802.1ad Q-in-Q VLAN headers are to be added. To make valid packets, input packets must already have 802.1q VLAN headers.

The Cisco HDLC header has a 1 byte "control" field. Apparently this should always be 0, but if you can use any 1 byte value.

The Cisco HDLC header has a 1 byte "address" field which has two valid values:

0x0F Unicast

0xBF Broadcast
You can however specify any single byte value.

Set the DLT value of the output pcap file.

Provide a series of comma deliminated hex values which will be used to rewrite or create the Layer 2 header of the packets. The first instance of this argument will rewrite both server and client traffic, but if this argument is specified a second time, it will be used for the client traffic.

Example:

    --user-dlink=01,02,03,04,05,06,00,1A,2B,3C,4D,5E,6F,08,00
    

in the range  0 through 5
    

If configured with --enable-debug, then you can specify a verbosity level for debugging output. Higher numbers increase verbosity.

Print nothing except the statistics at the end of the run

Allows you to select the packet timing method to use:

nano - Use nanosleep() API

select - Use select() API

ioport - Write to the i386 IO Port 0x80

gtod [default] - Use a gettimeofday() loop

Set a limit for the maximum number of milliseconds that tcpreplay will sleep between packets. Effectively prevents long delays between packets without effecting the majority of packets. Default is disabled.

When enabling verbose mode (-v) you may also specify one or more additional arguments to pass to tcpdump to modify the way packets are decoded. By default, -n and -l are used. Be sure to quote the arguments like: -A "-axxx" so that they are not interpreted by tcpreplay. Please see the tcpdump(1) man page for a complete list of options.

This option loads the specified pcap(s) into RAM before starting to send in order to improve replay performance while introducing a startup performance hit. Preloading can be used with or without --loop. This option also suppresses flow statistics collection for every iteration, which can significantly reduce memory usage. Flow statistics are predicted based on options supplied and statistics collected from the first loop iteration.

If you have a pcap file you would like to use to send bi-directional traffic through a device (firewall, router, IDS, etc) then using tcpprep you can create a cachefile which tcpreplay will use to split the traffic across two network interfaces.

If you captured network traffic using a network tap, then you can end up with two pcap files- one for each direction. This option will replay these two files at the same time, one on each interface and inter-mix them using the timestamps in each.

Required network interface used to send either all traffic or traffic which is marked as 'primary' via tcpprep. Primary traffic is usually client-to-server or inbound (RX) on khial virtual interfaces.

Optional network interface used to send traffic which is marked as 'secondary' via tcpprep. Secondary traffic is usually server-to-client or outbound (TX) on khial virtual interfaces. Generally, it only makes sense to use this option with --cachefile.

greater than or equal to 0
    

greater than or equal to 0
    

By default, tcpreplay will send packets based on the size of the "snaplen" stored in the pcap file which is usually the correct thing to do. However, occasionally, tools will store more bytes then told to. By specifying this option, tcpreplay will ignore the snaplen field and instead try to send packets based on the original packet length. Bad things may happen if you specify this option.

greater than or equal to 1
    

By default, tcpreplay will send all the packets. Alternatively, you can specify a maximum number of packets to send.

greater than or equal to 1
    

By default, tcpreplay will send all the packets. Alternatively, you can specify a maximum number of seconds to transmit.

Specify a value to modify the packet replay speed. Examples:

        2.0 will replay traffic at twice the speed captured
        0.7 will replay traffic at 70% the speed captured
    

Specify a value to regulate the packet replay to a specific packet-per-second rate. Examples:

        200 will replay traffic at 200 packets per second
        0.25 will replay traffic at 15 packets per minute
    

Specify a floating point value for the Mbps rate that tcpreplay should send packets at.

Allows you to step through one or more packets at a time.

greater than or equal to 1
    

When trying to send packets at very high rates, the time between each packet can be so short that it is impossible to accurately sleep for the required period of time. This option allows you to send multiple packets at a time, thus allowing for longer sleep times which can be more accurately implemented.

Ensure IPv4 and IPv6 packets will be unique for each --loop iteration. This is done in a way that will not alter packet CRC, and therefore will generally not affect performance. This option will significantly increase the flows/sec over generated over multiple loop iterations.

Number of --loop iterations before a new unique IP is assigned. Default is 1. Assumes both --loop and --unique-ip.

This feature will detect netmap capable network drivers on Linux and BSD systems. If detected, the network driver is bypassed for the execution duration, and network buffers will be written to directly. This will allow you to achieve full line rates on commodity network adapters, similar to rates achieved by commercial network traffic generators. Note that bypassing the network driver will disrupt other applications connected through the test interface. See INSTALL for more information.

This feature can also be enabled by specifying an interface as 'netmap:<intf>' or 'vale:<intf>. For example 'netmap:eth0' specifies netmap over interface eth0.

Number of seconds to delay after netmap is loaded. Required to ensure interfaces are fully up before netmap transmit. Requires netmap option. Default is 10 seconds.

Suppress the collection and printing of flow statistics. This option may improve performance when not using --preload-pcap option, otherwise its only function is to suppress printing.

The flow feature will track and print statistics of the flows being sent. A flow is loosely defined as a unique combination of a 5-tuple, i.e. source IP, destination IP, source port, destination port and protocol.

If --loop is specified, the flows from one iteration to the next will not be unique, unless the packets are altered. Use --unique-ip or tcpreplay-edit to alter packets between iterations.

greater than or equal to 0
    

This option will track and report flow expirations based on the flow idle times. The timestamps within the pcap file are used to determine the expiry, not the actual timestamp of the packets are replayed. For example, a value of 30 suggests that if no traffic is seen on a flow for 30 seconds, any subsequent traffic would be considered a new flow, and thereby will increment the flows and flows per second (fps) statistics.

This option can be used to optimize flow timeout settings for flow products. Setting the timeout low may lead to flows being dropped when in fact the flow is simply slow to respond. Configuring your flow timeouts too high may increase resources required by your flow product.

Note that using this option while replaying at higher than original speeds can lead to inflated flows and fps counts.

Default is 0 (no expiry) and a typical value is 30-120 seconds.

greater than or equal to 0
    

Note that timed delays are a "best effort" and long delays between sending packets may cause equally long delays between printing statistics.