On Fri, Jan 2, 2009 at 2:10 AM, Abdelrazak Younes <younes.ab...@gmail.com> wrote: [snip] > Aaron Turner wrote: >> >> I've occasionally toyed with the idea of creating >> a GUI, but frankly if you've ever seen a GUI I've created you'd know >> to never ask me to create one again. :) >> > > Never say never ;-)
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. My other UI's would make my own mother cry. >> Long story short, I know some C++ (not my favorite language, but I get >> by) and zero QT. >> > > I have to admit that C++ is my favorite language. But the good thing about > the C++/Qt combination is that you can pretty much let C++ advanced feature > out of the way (i.e. boost and stl). And we can decide to not use advanced > C++ in a first step: just C-like functions and small, very focused, classes. > My experience is that if you keep the classes small and focused the C++ > source code remain very flexible and understandable. > >> Anyways, I can't really offer much in the way of actual coding help, >> but I'd be more then happy to work with you on the design/testing/etc >> of the GUI. Honestly, I'd love to see a tcpreplay GUI- I'm sure it >> would really help a lot of people who have issues with command line >> tools with dozens of options like it has. >> >> Depending on how much free time and motivation you have maybe that's >> enough, if so great- if not, I understand. >> > > I'd like to make more use of tcpreplay in my new day-job, instead of > chariot. So I can justify working a bit on this GUI during my working hours > :-) > > As for the design, initially I plan to just offer some edit boxes and push > buttons for main commands. In a first step, the GUI will manage external > command-line process and communicate with tcpprep/tcprwrite/tcpreplay thanks > to pipes (stdin/out). That's how we manage LateX and external python script > within LyX and it work just fine. 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. 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 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. > 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. 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. > For the command definitions, in order to be flexible, I was thinking of a > simple INI like file format that will define the needed command. For > example: > > # TCP commands: > rw = /usr/local/bin/tcprewrite > pp = /usr/local/bin/tcpprep > rp = /usr/local/bin/tcpreplay > > # Rewrite TCP/UDP ports > rw_port = -r %1 > > # Rewrite source IP addresses using pseudo-NAT > rw_src_ip = -S %1 > > # Rewrite destination IP addresses using pseudo-NAT > rw_dst_ip = -D %1 > > # rewrite pcap file %1 into file %2 > rw_file = -i %1 -o %2 > > # Replay pcap file %2 on interface %1 > rp_play_file = -i %1 %2 > > The idea is to let the GUI construct the command line in an easy and > explicit way. What do you think? If you have a better idea or comments, > please don't hesitate. 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. > 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. 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 :) 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. Thanks! -- 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
