Here are trial and error logs when replaying a DNS capture file with tcpreply.
tcpreplay machine: 192.168.10.15
target machine (DNS Server): 192.168.10.12
install tcpreplay via apt-get
# tail -1 /etc/lsb-release
DISTRIB_DESCRIPTION="Ubuntu 13.04"
# uname -ri
3.8.0-35-generic x86_64
# apt-get install tcpreplay –y
# tcpreplay --version
tcpreplay version: 3.4.4 (build 2450) (debug)
Copyright 2000-2010 by Aaron Turner <aturner at synfin dot net>
Cache file supported: 04
Not compiled with libdnet.
Compiled against libpcap: 1.3.0
64 bit packet counters: enabled
Verbose printing via tcpdump: enabled
Packet editing: disabled
Fragroute engine: disabled
Injection method: PF_PACKET send()
|
prepare a capture data for tcpreplay.
on the tcpreplay box,
# tcpdump -i br0 udp dst port 53 -w dns_dump.cap
# dig @192.168.10.12 isc.org any +bufsize=4096 +ignore
# file dns_dump.cap
dns_dump.cap: tcpdump capture file (little-endian) - version 2.4 (Ethernet, capture length 65535)
|
replay the cap file
# tcpreplay --loop=1 --intf1=br0 dns_dump.cap
sending out br0
processing file: dns_dump.cap
Actual: 1 packets (78 bytes) sent in 0.03 seconds. Rated: 2600.0 bps, 0.02 Mbps, 33.33 pps
Statistics for network device: br0
Attempted packets: 1
Successful packets: 1
Failed packets: 0
Retried packets (ENOBUFS): 0
Retried packets (EAGAIN): 0
|
cap date on the NS server
# tshark -i eth0 port 53
Running as user "root" and group "root". This could be dangerous.
Capturing on eth0
0.000000 192.168.10.15 -> 192.168.10.12 DNS 78 Standard query 0x5718 ANY isc.org
|
checksum problem?
Let’s compare checksum between dig cap and tcpreplay cap.
[ dig cap ]
IP header
Total Length: 64
Identification: 0x43b6 (17334)
Flags: 0x00
0... .... = Reserved bit: Not set
.0.. .... = Don't fragment: Not set
..0. .... = More fragments: Not set
Fragment offset: 0
Time to live: 64
Protocol: UDP (17)
Header checksum: 0xa18b [correct]
[Good: True]
[Bad: False]
Source: 192.168.10.15 (192.168.10.15)
Destination: 192.168.10.12 (192.168.10.12)
|
UDP header
User Datagram Protocol, Src Port: domain (53), Dst Port: 60739 (60739)
Source port: domain (53)
Destination port: 60739 (60739)
Length: 44
Checksum: 0x95a9 [validation disabled]
[Good Checksum: False]
[Bad Checksum: False]
|
[ tcpreplay cap ]
IP header
Total Length: 64
Identification: 0x43aa (17322)
Flags: 0x00
0... .... = Reserved bit: Not set
.0.. .... = Don't fragment: Not set
..0. .... = More fragments: Not set
Fragment offset: 0
Time to live: 64
Protocol: UDP (17)
Header checksum: 0xa197 [correct]
[Good: True]
[Bad: False]
Source: 192.168.10.15 (192.168.10.15)
Destination: 192.168.10.12 (192.168.10.12)
|
UDP header
User Datagram Protocol, Src Port: 50164 (50164), Dst Port: domain (53)
Source port: 50164 (50164)
Destination port: domain (53)
Length: 44
Checksum: 0x95a9 [validation disabled]
[Good Checksum: False]
[Bad Checksum: False]
|
It seems that there are no problems about checksum, I think.
How about using a cap file captured with tshark
# tshark -i br0 udp dst port 53 -w tshark_dig.pcap
# dig @192.168.10.12 isc.org any +bufsize=4096
# file tshark_dig.pcap
tshark_dig.pcap: pcap-ng capture file - version 1.0
# tcpreplay --loop=1 --intf1=br0 tshark_dig.pcap
sending out br0
processing file: tshark_dig.pcap
Actual: 1 packets (78 bytes) sent in 0.04 seconds. Rated: 1950.0 bps, 0.01 Mbps, 25.00 pps
Statistics for network device: br0
Attempted packets: 1
Successful packets: 1
Failed packets: 0
Retried packets (ENOBUFS): 0
Retried packets (EAGAIN): 0
|
same issue. DNS server does not replay the answer.
# tshark -i eth0 port 53
Running as user "root" and group "root". This could be dangerous.
Capturing on eth0
0.000000 192.168.10.15 -> 192.168.10.12 DNS 78 Standard query 0xf9d4 ANY isc.org
|
How about re-calculating checksum with tcprewrite
[ tcprewrite: tcpdump cap file ]
# tcprewrite --fixcsum --infile=dns_dump.cap --outfile=out_dns_dump.cap
|
# tcpreplay --loop=1 --intf1=br0 out_dns_dump.cap
sending out br0
processing file: out_dns_dump.cap
Actual: 1 packets (78 bytes) sent in 0.03 seconds. Rated: 2600.0 bps, 0.02 Mbps, 33.33 pps
Statistics for network device: br0
Attempted packets: 1
Successful packets: 1
Failed packets: 0
Retried packets (ENOBUFS): 0
Retried packets (EAGAIN): 0
|
Okay.
190.106051 192.168.10.15 -> 192.168.10.12 DNS 78 Standard query 0x5718 ANY isc.org
190.106191 192.168.10.12 -> 192.168.10.15 DNS 78 Standard query response 0x5718
|
I was able to replay pcap file from both tcpdump pcap and tshark pcap after issuing fixing checksum with tcprewrite.
[ tcprewrite: tshark cap file ]
# tcprewrite --fixcsum --infile=tshark_dig.pcap --outfile=out_tshark_dig.pcap
# tcpreplay --loop=1 --intf1=br0 out_tshark_dig.pcap
sending out br0
processing file: out_tshark_dig.pcap
Actual: 1 packets (78 bytes) sent in 0.03 seconds. Rated: 2600.0 bps, 0.02 Mbps, 33.33 pps
Statistics for network device: br0
Attempted packets: 1
Successful packets: 1
Failed packets: 0
Retried packets (ENOBUFS): 0
Retried packets (EAGAIN): 0
|
Okay.
382.992509 192.168.10.15 -> 192.168.10.12 DNS 78 Standard query 0xf9d4 ANY isc.org
382.992657 192.168.10.12 -> 192.168.10.15 DNS 78 Standard query response 0xf9d4
|
Seen from the result, the problem on this issue seemed to be caused by checksum..
Seen from the tcpreplay documents, it describes that
Forcing Checksum Calculation
Many network cards support TCP/UDP/IP checksum offloading, so if you capture traffic which was generated by the same system, the checksums will be incorrect. This can obviously cause problems later on when you try replaying the traffic. By using the --fixcsum flag, you can force tcprewrite to fix the checksums. Note, tcprewrite will automatically fix checksums when editing packets.
$ tcprewrite --fixcsum --infile=input.pcap --outfile=output.pcap
|
[ sample usage ]
replay the cap file at top speed
# tcpreplay --loop=1000 -t -q --intf1=br0 out_dns_dump.cap
|
--loop=1000 : repeat 1,000 times
--loop=0: repeat forever until Ctrl-C is pressed
send 1,000 pps
# tcpreplay -q --loop=100 --pps=1000 --intf1=br0 out_dns_dump.cap
|