On Tue, Jan 6, 2009 at 5:09 AM, Abdelrazak Younes
<younes.ab...@gmail.com> wrote:
> Aaron Turner wrote:
>> On Mon, Jan 5, 2009 at 1:31 AM, Abdelrazak Younes
>>>>
>>>> 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...
I say "to a server" since that's what most people want to do. But you
could easily replace that with "to a client". Really what I mean in
#2 and #3 is that the device under test is an endpoint (that's
actually how I labeled it in the GUI workflow). #2 is different from
#3 in that you would never change the destination IP of a multicast
packet when using tcprewrite because that would break the protocol.
[snip about CMake]
> 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.
Yeah, there seems to be some things that CMake won't do that come for
free with the autotools ("make dist" for example), but from a
philosophical point of view I'd like to only have one build system.
>From a pragmatic point of view, I suspect there will be two for a
while at least. Anyways looks like Wireshark is slowly trying to move
to CMake, but nobody has pulled a KDE and just done it. Hence Windows
is built with hand rolled make files which obviously don't help the
MSVC IDE people much.
Unfortunately, it sounds like moving to CMake to build MSVC project
files doesn't mean the integrated debugger works- apparently there's
some other file(s) necessary for that. :(
Anyways, once 3.4 is out the door, I'll probably start playing with
CMake in a feature branch and see what I think of it.
>> 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).
No worries. Funny how being out of the office for the holidays means
the work just piles up on your desk. :) One thing that isn't captured
in the flow diagram is that it would be nice if certain editing
features are disabled by default/required depending on the use case.
For example, if you say inline-proxy-arp or router, we know you need
to edit the MAC addresses, but there's probably no need to do that for
a transparent device. Something to keep in mind for later.
Anyways, I'll probably ping you in a couple of weeks to see how things
are going. Hopefully by then 3.4 will be out the door.
--
Aaron Turner
http://synfin.net/
http://tcpreplay.synfin.net/ - Pcap editing and replay tools for Unix & Windows
They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety. -- Benjamin Franklin
------------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
_______________________________________________
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
