Re: [Tcpreplay-users] Problem with --enable-local-libopts

[Abdelrazak Y. <you...@gm...>]

On 02/01/2009 20:12, Aaron Turner wrote:
> Well let me put it this way- my UI's are notoriously horrible- most if
> not all of the people who have seen them intentionally keep me away
> from UI work ever since. :)   By far the best UI I've ever done is
> this: http://cabernetdemo.synfin.net.

Hey, who said that Americans don't know about wine? :-)
Pretty impressed!

>
> That would definitely work as a good first step.  My long term goal is
> having a GUI which walks a user through the necessary steps in order
> to take the pcap they have and test the device in question.
> Basically, moving tcpreplay from a set of tools and into a unified
> solution.  Maybe this is a wizard or possibly different views.
Yes, a wizard for creating config files for common use cases would be 
very nice. And this fits well with your configuration solution described 
below.Wizards are easily created with Qt (see 
http://doc.trolltech.com/4.4/dialogs-classwizard.html) so if you can 
describe the ui that you want and the number of step, I guess I can code 
an example one.

>   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.

> All may include source IP/MAC rewriting if their testbed requires it.
>
> And of course any of these use cases may have requirements for editing
> layer 4+: rewriting destination ports, fixing checksums, etc.  For
> numbers 4, 5 & 6- a big issue is using tcpprep to split traffic- there
> are a lot of different ways to do it, but people generally have a hard
> time picking the best one.  That may just be a documentation issue-
> not sure what a UI can do to help.
>   

People just don't read the documentation. That's a sad but true fact. 
And that's when GUIs are especially useful; my ideal GUI is a self 
documented, obvious GUI :-)

>  
>> In a second step,  if needed and if tcpreplay evolves toward creating a
>> library, we can replace some of the instantaneous commands with library
>> function calling. Do you have any plan for such a library? This will for
>> sure facilitate the porting to Windows/MSVC.
>>     
>
> Having Windows support would be VERY useful.  If you're willing to
> help define the API, I'd be willing to make tcpreplay, tcpprep &
> tcprewrite a library.  Most of the editing code in tcprewrite is
> already a library (libtcpedit).  Right now I'm estimating 25-40% of
> the users are Windows and leaving them out would suck- especially
> since they're the one's who have the most trouble with CLI's.
>
> The one "issue" with Windows/MSVC is obviously that current Windows
> support is done via Cygwin and I have zero Windows programming
> experience.  Obviously there is a porting effort involved here if we
> go that route and I don't even know enough to tell you how much work
> that would be.  I remember hearing about add-ons for Windows which
> gave it POSIX support but I don't know if that's still true or how
> well it works/if it would help here.
>   

There are such libraries indeed but they are not well maintained AFAIR. 
The best solution is to use cross platform libraries for file access, 
etc. I used to be a Windows/MSVC guy so I probably can help here too.

> I'm pretty sure AutoGen won't work natively under Windows (it requires
> guile), but we'd be moving to an API model anyways, so it wouldn't
> really matter since that's just used to parse CLI options/config
> files.  I've been pretty good about keeping all the AutoGen macro
> usage limited to the initialization stage to fill out a config struct
> which is then passed around internally- so doing the API thing
> shouldn't require any heavy lifting.
>   

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.


> One idea if we initially go the fork()/pipe route is to use config
> file templates.  Tcpreplay already supports configuration files for
> all its options so using templates would make things even easier IMHO.
>  Basically, you'd define a template or partial template for each
> situation and write a config file which you'd pass directly to
> tcpreplay/tcpprep/tcprewrite.  Honestly though, I'd rather see (and
> would be willing to help more with) going the API route.  You can find
> an example config file as test/config.  The nice thing about this is
> that people could save the config files for later to use in automated
> test beds/scripted environments.
>   

That's good indeed. I'll try to go that route.

>  
>> As for the GUI proper, I was thinking of hiding the initial temporary 
>> file
>> generated by tcprewrite. I can work a minimal demo app  with the 
>> following
>> example. Three edit boxes for port, destination IP and MAC, one edit 
>> box for
>> pcap input file. The source IP and mac addresses will be directly  
>> decided
>> by the GUI. As a picture is worth a thousand words, I attach a 
>> screenshot of
>> a designer file that I just created. Obviously, I decided on which 
>> controls
>> make sense based on my pretty dumb specific use case but nothing is 
>> set in
>> stone of course.
>>     
>
> So in my world, the tcprewrite files are useful to keep around because
> I tend to deal with large files and I care about reproducibility (edit
> once, replay many times).  Now, not everyone is like that so I'm cool
> with keeping them temporarily around for the initial version, but
> perhaps with a checkbox which tells the GUI to not delete them.
>   

OK.

> In a perfect world, the UI would provide some basic file management so
> you can keep track of what tcpprep cache files go with what pcaps as
> well as what relations pcaps have with each other (ie: these 3 pcaps
> are children/edited copies of this other pcap).  But that's my dream
> world for version 5.0 of the UI :)
>   

Yeah, step by step :-)

> Anyways, that's my thoughts- why don't you think it over and figure
> out how much time you can realistically set aside for this and let me
> know if and how you'd like to move forward.  Honestly, I'd rather have
> a GUI which solves 20% of the use cases then one which would solve
> 100% of them but never gets completed because you ran out of time.
> Hence, I'd suggest something small and focused, but creates the
> foundation for other people to extend it in the future.  The mockup
> you did would be a fine start IMHO.
>   

OK, I'll keep you updated. I am pretty busy this week but I'll try to do 
this initial demo by next week or the one after.

Cheers and happy new year,
Abdel.