Aaron Turner wrote: > On Mon, Jan 5, 2009 at 1:31 AM, Abdelrazak Younes > >>> When I >>> look at the questions people have about tcpreplay, they often not only >>> don't know how to do certain things with tcpreplay, but often they >>> don't even know what they *need* to do. >>> >>> A good example is replaying UDP traffic to a server. People know they >>> have to change the destination IP, but often forget to change the >>> destination MAC address too. >>> >>> The major use cases seem to be: >>> 1. Playing traffic at a sniffer (simplest case) >>> 2. UDP multicast to a server (also very simple) >>> 3. ICMP/UDP unicast traffic to a server >>> 4. Playing traffic through a transparent device (firewall, IPS) >>> 5. Playing traffic through a proxy-arp device >>> 6. Playing traffic through a router >>> >>> >> Here is my use case: I want to stress test the communication between two >> PLC plugs with regard to voip streams, video streams (all sorts, >> multicast, unicast), TCP or UDP, and normal http or ftp streams. The PLC >> have acess to a number of QoS parameters than can be fine tuned for >> proper video and or voice transmission. So I want to replay streams >> where I can modify the IP/MAC destination and VLAN or TOS bits for example. >> > > So does your PLC fit one of the above 6 use cases?
I guess 2 and 3 are but I am not sure what 2 and 3 means, I would have said _from_ a server instead of _to_ a server. For example I would like to mimic UDP (or RTP) multicast or unicast video traffic between an ADSL modem and a Set Top Box (STB). In order to do that I would record the stream out of the modem (thanks to wireshark or tcpdump) and intended to the STB. At the same time I would like mimic a TCP http connection for example or a VoIP communication. I am not sure I am clear... > About the only > issue I see is TOS- which isn't currently supported in tcprewrite, but > that should be easy for me to fix. (I just opened ticket #348 to > track it). > Great! >> Would you be open to move to another build system? CMake is very nice >> and quite popular these days and its MSVC support is excellent. >> > > Yes, I would be open to moving to cmake if it indeed makes sense. I > would probably look around at other projects like Wireshark to see how > they handle this as well. Honestly, I'd rather not rewrite/debug all > the auto* code which handles the various UNIX variants just to add > Windows support, so I'd rather handle the MSVC build independently. > I understand. And that's by the way what we are doing within LyX project; we have 3 build systems, autotools, scons and CMake. The reason why we didn't switch to scons or cmake is that nobody took the time to make sure that all unix variants are still supported. Still, MSVC and Mac developers use cmake, Windows packagers uses scons, Mac and Linux packagers use autotools. We've been doing that for two years without headache. Maintaining cmake or scons is very simple once the initial script development is done. > Happy new year to you too! If this actually happens, I think 2009 > will be a great year for Tcpreplay! > > Anyways, I'll try to get you a flow chart for the wizard and a > suggestion for how to organize the features for a tabbed interface. > Got it, I'll probably have questions once I start looking into it (not in the coming week or two). > Right now I'm working on v3.4 and fixing the 802.11 DLT editor (which > is pretty broken right now). However, I think a GUI is far more > interesting then some of the other features planned for 3.4, so I'll > probably punt on those for now so I can get 3.4 out the door and start > looking into a native Windows build. > That'd be great. Abdel. ------------------------------------------------------------------------------ _______________________________________________ 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
