On Mon, Jan 5, 2009 at 1:31 AM, Abdelrazak Younes <younes.ab...@gmail.com> wrote: > 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!
Don't confuse the ability to write a RoR application with being a wine expert. :) >> 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. So does your PLC fit one of the above 6 use cases? 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). Anyways, you asked for a description of how the wizard should work. Let me think about it a little and come up with a flow chart. I'll try to get that to you by tomorrow. Also, I'm not married to the idea of a wizard- if feel another solution is easier to implement (perhaps a tabbed UI broken up into sections) then let me know. I'd rather have something which works then the perfect solution which never gets implemented. :) >> 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 :-) Agreed. Also, GUI's provide users some guidance and feedback of how to use a tool- something a CLI with a bunch of options doesn't. Basically, GUI's create visual constraints/feedback on usage while CLI's appear to be boundless which means people quickly get overwhelmed. >>> 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 already use winpcap for reading/writing pcap files & packets onto the network which is the big part. AutoGen/AutoOpts would be replaced by the QT GUI. The rest of it is pretty standard POSIX code which I don't think will be too difficult to port over. >> 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. 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. >> 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. 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. 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. Regards, Aaron -- 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 ------------------------------------------------------------------------------ _______________________________________________ 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
