I found the solution to my problem and hopefully something that can
help to explain why the network connection was frozen while the file
was being replayed.
The pcap file I'm using has been recorded from a mobile phone network
and is made out of messages whose protocol stack is: ETHERNET + IP +
SCTP + MTP3 UA + SCCP + RANAP + CC/MM/SMS. These messages are sent
between network devices in the 10.53.X.X network, so I was generating
my cache file using the command:
tcpprep --cidr=10.0.0.0/8 --pcap=original.pcap --cache=cache.cache
And then rewrite the original pcap file to play it on my network:
tcprewrite --endpoints=172.30.2.65:172.30.2.60
--enet-dmac=00:00:00:00:00:AA --enet-smac=00:00:00:00:00:BB
--cachefile=cache.cache --infile=original.pcap
--outfile=tobeplayed.pcap --skipbroadcast
So in the new pcap file all the mobile phone network traffic was going
to be sent from 172.30.2.65 to 172.30.2.60 when I played this file
with the following command:
tcpreplay --intf1=eth0 tobeplayed.pcap
The traffic was sent as expected to the other end, but the network
interface was not responding while playing the file. That is, the
network interface didn't respond to any outgoing or incoming traffic
different from the pcap file being played until the file was finished.
Now, I changed the command below to :
tcpreplay --intf1=eth0 --intf2=eth1 --cachefile=cache.cache tobeplayed.pcap
The network connection doesn't die while I play the file like this!
Even though eth1 is not connected to anything (I had to run "ifconfig
eth1 up' first to be able to use eth1). This is the output of playing
the whole file:
~/tcpreplay$ sudo tcpreplay --mbps=10 --intf1=eth0 --intf2=eth1
--cachefile=Interface1_1.cache Interface1_1_ToDesktop.pcap
sending out eth0 eth1
processing file: Interface1_1_ToDesktop.pcap
Actual: 440557 packets (201428436 bytes) sent in 153.53 seconds
Rated: 1311964.6 bps, 10.01 Mbps/sec, 2869.48 pps
Statistics for network device: eth0
Attempted packets: 439989
Successful packets: 439989
Failed packets: 0
Retried packets: 0
Statistics for network device: eth1
Attempted packets: 568
Successful packets: 568
Failed packets: 0
Retried packets: 0
This was completely surprising for me. Why is there any traffic in
eth1? I went on investigating and went back to my original pcap file.
It turns out that not all the traffic on it is being sent in the
10.53.X.X network, some other messages (not part of the real mobile
phone network such as ARP, NetBIOS...) are included in the same file.
My theory is that when I create the cache file using tcpprep I
'usecidr=10.0.0.0/8' so all the messages originally sent over those ip
addresses are played through the interface eth0, but any other message
is sent through eth1, including the ARP broadcasts, DHCP, etc.
I don't know if the problem is _me_ forcing tcpreplay to do something
I should be doing in another way, or it is a bug in tcpreplay that I
need that extra interface for tcpreplay not to hang my network
connection. It looks like the application expects to send some traffic
from some other interface different of eth0, and the packet is hanging
around in some buffer until tcpreplay is done with the file.
Thanks,
Faustino
------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
Tcpreplay-users mailing list
Tcpreplay-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tcpreplay-users
Support Information: http://tcpreplay.synfin.net/trac/wiki/Support
