Hi Faustino, What it sounds like is there's some packet(s) that are being sent out eth1 that is screwing up your eth0 NIC/network. Without looking at the packets, I really can't say why, but tcpreplay (unlike tcpprep) doesn't do any decoding of packets and treats each packet exactly the same way.
Anyways, to answer your question, the reason you see packets going out eth1 is because you're using a cache file and tcpreplay uses that to select which interface a packet should go out. When you're splitting traffic like that, tcpprep only looks at the SOURCE IP of the packet. Anything traffic with a source address outside of 10/8 would go out eth1. You can use tcpprep --print-info and tcpreplay --verbose to see how tcpprep classified traffic. Generally speaking, people send ARP, NetBIOS, broadcast and multicast traffic out via tcpreplay all the time and don't have any problems like you're reporting. So far, nothing you've told me leads me to believe there is a bug in tcpreplay. Under Linux, tcpreplay uses the standard PF_PACKET socket API which is intended specifically for this type of purpose. Anyways, your hypothesis is correct- non-IP traffic such as ARP is considered "client" traffic by default and will be sent out the second interface (eth1 in your case). You can change this behavior using the tcpprep --nonip flag. Since you only specified a IPv4 address range, IPv6 traffic would also fall under this category. Regards, Aaron On Tue, Jun 9, 2009 at 10:09 AM, Faustino Frechilla<frechi...@gmail.com> wrote: > 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. > -- Aaron Turner http://synfin.net/ http://tcpreplay.synfin.net/ - Pcap editing and replay tools for Unix & Windows Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin ------------------------------------------------------------------------------ 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
