Menu
▾
▴
tcpreplay-users
|
From: Abdelrazak Y. <yo...@ly...> - 2008-12-31 09:35:46
|
Hello, In http://tcpreplay.synfin.net/trac/wiki/Developer#DeveloperNotes, I read that I should use --enable-local-libopts I don't know if this is an old page but I get this error: younes@younes:~/devel/pcap/tcpreplay$ ./autogen.sh libtoolize: `AC_PROG_RANLIB' is rendered obsolete by `LT_INIT' younes@younes:~/devel/pcap/tcpreplay$ ./configure --enable-local-libopts ... checking for autogen version >= 5.9.x... yes configure: error: Your version of autogen (5.9.5) != libopts tear off (5.9.2) Either install the correct version or specify --disable-local-libopts I am reporting this just in case it is not known. Abdel. |
|
From: Abdelrazak Y. <you...@gm...> - 2008-12-31 09:38:59
|
Hello, In http://tcpreplay.synfin.net/trac/wiki/Developer#DeveloperNotes, I read that I should use --enable-local-libopts I don't know if this is an old page but I get this error: younes@younes:~/devel/pcap/tcpreplay$ ./autogen.sh libtoolize: `AC_PROG_RANLIB' is rendered obsolete by `LT_INIT' younes@younes:~/devel/pcap/tcpreplay$ ./configure --enable-local-libopts ... checking for autogen version >= 5.9.x... yes configure: error: Your version of autogen (5.9.5) != libopts tear off (5.9.2) Either install the correct version or specify --disable-local-libopts I am reporting this just in case it is not known. Abdel. PS: Sorry Aaron for the double post if it comes. I send the first mail from gmane without noticing. |
|
From: Abdelrazak Y. <you...@gm...> - 2008-12-31 09:45:54
|
Abdelrazak Younes wrote: > Hello, > > In http://tcpreplay.synfin.net/trac/wiki/Developer#DeveloperNotes, I > read that I should use --enable-local-libopts > > I don't know if this is an old page but I get this error: > > younes@younes:~/devel/pcap/tcpreplay$ ./autogen.sh > libtoolize: `AC_PROG_RANLIB' is rendered obsolete by `LT_INIT' > younes@younes:~/devel/pcap/tcpreplay$ ./configure --enable-local-libopts > ... > checking for autogen version >= 5.9.x... yes > configure: error: Your version of autogen (5.9.5) != libopts tear off > (5.9.2) Either install the correct version or specify > --disable-local-libopts Please tell me if this kind of report is needed or maybe the svn version is too unstable at the moment? When I configure without any option, I get this: ########################################################################## TCPREPLAY Suite Configuration Results (3.4.0) ########################################################################## libpcap: /usr/local (>= 0.9.6) libdnet: no () autogen: /usr/bin/autogen (5.9.5) Use libopts tearoff: yes 64bit counter support: yes tcpdump binary path: /usr/local/sbin/tcpdump tcpreplay edit support: no tcpbridge support: yes fragroute support: no Supported Packet Injection Methods (*): Linux PF_PACKET: yes BSD BPF: no libdnet: no pcap_inject: yes pcap_sendpacket: yes And then I get a lot of warnings (I can report them if you want) and a compilation error: make[4]: Leaving directory `/home/younes/devel/pcap/tcpreplay/src/tcpedit' make[3]: Leaving directory `/home/younes/devel/pcap/tcpreplay/src/tcpedit' make[3]: Entering directory `/home/younes/devel/pcap/tcpreplay/src' /usr/bin/autogen -L tcpedit tcpreplay_opts.def if gcc -DHAVE_CONFIG_H -I. -I. -I. -I../libopts -I.. -DTCPREPLAY -D_U_="__attribute__((unused))" -Wall -O3 -std=gnu99 -Wextra -Wno-variadic-macros -Wfatal-errors -I/usr/local/include -MT tcpreplay-tcpreplay_opts.o -MD -MP -MF ".deps/tcpreplay-tcpreplay_opts.Tpo" -c -o tcpreplay-tcpreplay_opts.o `test -f 'tcpreplay_opts.c' || echo './'`tcpreplay_opts.c; \ then mv -f ".deps/tcpreplay-tcpreplay_opts.Tpo" ".deps/tcpreplay-tcpreplay_opts.Po"; else rm -f ".deps/tcpreplay-tcpreplay_opts.Tpo"; exit 1; fi In file included from tcpreplay_opts.c:56: tcpreplay_opts.h:72:3: error: #error option template version mismatches autoopts/options.h header In file included from tcpreplay_opts.c:56: tcpreplay_opts.h:73: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘Me’ compilation terminated due to -Wfatal-errors. make[3]: *** [tcpreplay-tcpreplay_opts.o] Error 1 make[3]: Leaving directory `/home/younes/devel/pcap/tcpreplay/src' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/younes/devel/pcap/tcpreplay/src' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/younes/devel/pcap/tcpreplay/src' make: *** [all-recursive] Error 1 Abdel. |
|
From: Aaron T. <syn...@gm...> - 2009-01-01 20:43:16
|
The developer notes section you're referring to is my release checklist. It's pretty specific to *my* development environment so that I don't release broken code (again). It doesn't actually have anything to do with building the source tree for normal use. My suggestion to everyone is usually "grab the tarball" since the tarball is actually different from the code checked out of svn. I never check in generated code as a matter of policy. However, since you're talking about doing some development, the issue you're running into is because the version of GNU Autogen/AutoOps installed on your system is different then the version included with tcpreplay in the libopts directory. Autogen/AutoOpts is very finicky about versioning. What I would recommend is follow the directions here: http://tcpreplay.synfin.net/trac/wiki/manual#GettingTcpreplayInstalled Specifically the part about using --disable-local-libopts and --disable-libopts-install. This will cause tcpreplay to link against your system version of autogen/autoopts which was used to generate the src/*_opts.[ch] files when you run make (they're not in SVN since they're generated source files, but they're included in the tarballs). If that doesn't work, i'll be happy to work with you on irc (#tcpreplay on freenode). 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 On Wed, Dec 31, 2008 at 1:45 AM, Abdelrazak Younes <you...@gm...> wrote: > Abdelrazak Younes wrote: >> Hello, >> >> In http://tcpreplay.synfin.net/trac/wiki/Developer#DeveloperNotes, I >> read that I should use --enable-local-libopts >> >> I don't know if this is an old page but I get this error: >> >> younes@younes:~/devel/pcap/tcpreplay$ ./autogen.sh >> libtoolize: `AC_PROG_RANLIB' is rendered obsolete by `LT_INIT' >> younes@younes:~/devel/pcap/tcpreplay$ ./configure --enable-local-libopts >> ... >> checking for autogen version >= 5.9.x... yes >> configure: error: Your version of autogen (5.9.5) != libopts tear off >> (5.9.2) Either install the correct version or specify >> --disable-local-libopts > > Please tell me if this kind of report is needed or maybe the svn version > is too unstable at the moment? > > When I configure without any option, I get this: > > ########################################################################## > > TCPREPLAY Suite Configuration Results > (3.4.0) > ########################################################################## > > libpcap: /usr/local (>= > 0.9.6) > libdnet: no > () > autogen: /usr/bin/autogen > (5.9.5) > Use libopts tearoff: > yes > 64bit counter support: > yes > tcpdump binary path: > /usr/local/sbin/tcpdump > tcpreplay edit support: > no > tcpbridge support: > yes > fragroute support: > no > > Supported Packet Injection Methods (*): > Linux PF_PACKET: yes > BSD BPF: no > libdnet: no > pcap_inject: yes > pcap_sendpacket: yes > > And then I get a lot of warnings (I can report them if you want) and a > compilation error: > > make[4]: Leaving directory `/home/younes/devel/pcap/tcpreplay/src/tcpedit' > make[3]: Leaving directory `/home/younes/devel/pcap/tcpreplay/src/tcpedit' > make[3]: Entering directory `/home/younes/devel/pcap/tcpreplay/src' > /usr/bin/autogen -L tcpedit tcpreplay_opts.def > if gcc -DHAVE_CONFIG_H -I. -I. -I. -I../libopts -I.. -DTCPREPLAY > -D_U_="__attribute__((unused))" -Wall -O3 -std=gnu99 -Wextra > -Wno-variadic-macros -Wfatal-errors -I/usr/local/include -MT > tcpreplay-tcpreplay_opts.o -MD -MP -MF > ".deps/tcpreplay-tcpreplay_opts.Tpo" -c -o tcpreplay-tcpreplay_opts.o > `test -f 'tcpreplay_opts.c' || echo './'`tcpreplay_opts.c; \ > then mv -f ".deps/tcpreplay-tcpreplay_opts.Tpo" > ".deps/tcpreplay-tcpreplay_opts.Po"; else rm -f > ".deps/tcpreplay-tcpreplay_opts.Tpo"; exit 1; fi > In file included from tcpreplay_opts.c:56: > tcpreplay_opts.h:72:3: error: #error option template version mismatches > autoopts/options.h header > In file included from tcpreplay_opts.c:56: > tcpreplay_opts.h:73: error: expected '=', ',', ';', 'asm' or > '__attribute__' before 'Me' > compilation terminated due to -Wfatal-errors. > make[3]: *** [tcpreplay-tcpreplay_opts.o] Error 1 > make[3]: Leaving directory `/home/younes/devel/pcap/tcpreplay/src' > make[2]: *** [all-recursive] Error 1 > make[2]: Leaving directory `/home/younes/devel/pcap/tcpreplay/src' > make[1]: *** [all] Error 2 > make[1]: Leaving directory `/home/younes/devel/pcap/tcpreplay/src' > make: *** [all-recursive] Error 1 > > Abdel. |
|
From: Aaron T. <syn...@gm...> - 2009-01-02 17:36:16
|
Glad that got things working for you. I was suggesting IRC because if that didn't solve your problem, then you've got a problem I've never seen and I figured it would be easier to work it out over IRC then email. Generally speaking either works. Anyways, thanks for the warnings- I'm still using gcc 4.0 for the most part and so I don't get warnings except those in the *_opts.c files. -Aaron On Fri, Jan 2, 2009 at 2:20 AM, Abdelrazak Younes <you...@gm...> wrote: > Aaron Turner wrote: >> What I would recommend is follow the directions here: >> http://tcpreplay.synfin.net/trac/wiki/manual#GettingTcpreplayInstalled >> >> Specifically the part about using --disable-local-libopts and >> --disable-libopts-install. >> >> This will cause tcpreplay to link against your system version of >> autogen/autoopts which was used to generate the src/*_opts.[ch] files >> when you run make (they're not in SVN since they're generated source >> files, but they're included in the tarballs). >> > > OK, I did that and it compiled fine thanks. I had a number of warnings > that I pasted below just in case you are interested in having a look. > This is with gcc 4.3.3. > >> If that doesn't work, i'll be happy to work with you on irc >> (#tcpreplay on freenode). >> > > I have to admit I have never used irc. For LyX development we > communicate exclusively on the development mailing list. But I can try > if that's your preferred medium. > > Thanks, > Abdel. |
|
From: Aaron T. <syn...@gm...> - 2009-01-02 19:51:47
|
Quick question: if you compile without --enable-debug on 4.3.3, and run (as root) 'make test' do you get a bunch of errors (exit code 255) or passes? Under OSX's 4.2 (which I just tried) it works just find under --enable-debug but fails horribly without. Strange. Thanks, Aaron On Fri, Jan 2, 2009 at 9:36 AM, Aaron Turner <syn...@gm...> wrote: > Glad that got things working for you. I was suggesting IRC because if > that didn't solve your problem, then you've got a problem I've never > seen and I figured it would be easier to work it out over IRC then > email. Generally speaking either works. > > Anyways, thanks for the warnings- I'm still using gcc 4.0 for the most > part and so I don't get warnings except those in the *_opts.c files. > > -Aaron > > On Fri, Jan 2, 2009 at 2:20 AM, Abdelrazak Younes > <you...@gm...> wrote: >> Aaron Turner wrote: >>> What I would recommend is follow the directions here: >>> http://tcpreplay.synfin.net/trac/wiki/manual#GettingTcpreplayInstalled >>> >>> Specifically the part about using --disable-local-libopts and >>> --disable-libopts-install. >>> >>> This will cause tcpreplay to link against your system version of >>> autogen/autoopts which was used to generate the src/*_opts.[ch] files >>> when you run make (they're not in SVN since they're generated source >>> files, but they're included in the tarballs). >>> >> >> OK, I did that and it compiled fine thanks. I had a number of warnings >> that I pasted below just in case you are interested in having a look. >> This is with gcc 4.3.3. >> >>> If that doesn't work, i'll be happy to work with you on irc >>> (#tcpreplay on freenode). >>> >> >> I have to admit I have never used irc. For LyX development we >> communicate exclusively on the development mailing list. But I can try >> if that's your preferred medium. >> >> Thanks, >> Abdel. > -- 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 |
|
From: Abdelrazak Y. <you...@gm...> - 2009-01-05 09:31:30
|
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. |
|
From: Abdelrazak Y. <you...@gm...> - 2009-01-06 13:09:14
|
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. |
|
From: Abdelrazak Y. <you...@gm...> - 2009-01-02 10:20:14
|
Aaron Turner wrote: > What I would recommend is follow the directions here: > http://tcpreplay.synfin.net/trac/wiki/manual#GettingTcpreplayInstalled > > Specifically the part about using --disable-local-libopts and > --disable-libopts-install. > > This will cause tcpreplay to link against your system version of > autogen/autoopts which was used to generate the src/*_opts.[ch] files > when you run make (they're not in SVN since they're generated source > files, but they're included in the tarballs). > OK, I did that and it compiled fine thanks. I had a number of warnings that I pasted below just in case you are interested in having a look. This is with gcc 4.3.3. > If that doesn't work, i'll be happy to work with you on irc > (#tcpreplay on freenode). > I have to admit I have never used irc. For LyX development we communicate exclusively on the development mailing list. But I can try if that's your preferred medium. Thanks, Abdel. In function ‘snprintf’, inlined from ‘cidr2iplist’ at cidr.c:509: /usr/include/bits/stdio2.h:65: warning: call to __builtin___snprintf_chk will always overflow destination buffer cache.c: In function ‘read_cache’: cache.c:116: warning: format ‘%d’ expects type ‘int’, but argument 4 has type ‘ssize_t’ cache.c:141: warning: format ‘%ld’ expects type ‘long int’, but argument 4 has type ‘long long unsigned int’ cache.c: In function ‘write_cache’: cache.c:188: warning: format ‘%d’ expects type ‘int’, but argument 3 has type ‘ssize_t’ cache.c:188: warning: format ‘%d’ expects type ‘int’, but argument 4 has type ‘long unsigned int’ cache.c:198: warning: format ‘%d’ expects type ‘int’, but argument 3 has type ‘ssize_t’ cache.c:198: warning: format ‘%d’ expects type ‘int’, but argument 4 has type ‘size_t’ cache.c:221: warning: format ‘%i’ expects type ‘int’, but argument 3 has type ‘ssize_t’ get.c: In function ‘get_l2len’: get.c:146: warning: unused variable ‘ether_type’ fakepoll.c:43: warning: ‘FAKEPOLL’ defined but not used xX.c: In function ‘parse_xX_str’: xX.c:101: warning: implicit declaration of function ‘exit’ xX.c:101: warning: incompatible implicit declaration of built-in function ‘exit’ xX.c:108: warning: incompatible implicit declaration of built-in function ‘exit’ utils.c: In function ‘_our_safe_malloc’: utils.c:58: warning: format ‘%d’ expects type ‘int’, but argument 3 has type ‘const char *’ utils.c:58: warning: too many arguments for format utils.c: In function ‘_our_safe_realloc’: utils.c:83: warning: format ‘%d’ expects type ‘int’, but argument 3 has type ‘const char *’ utils.c:83: warning: too many arguments for format utils.c: In function ‘_our_safe_strdup’: utils.c:102: warning: format ‘%d’ expects type ‘int’, but argument 3 has type ‘const char *’ utils.c:102: warning: too many arguments for format utils.c: In function ‘_our_safe_free’: utils.c:119: warning: too many arguments for format sendpacket.c: In function ‘sendpacket_close’: sendpacket.c:412: warning: enumeration value ‘SP_TYPE_LIBNET’ not handled in switch sendpacket.c:412: warning: enumeration value ‘SP_TYPE_LIBDNET’ not handled in switch sendpacket.c:412: warning: enumeration value ‘SP_TYPE_LIBPCAP’ not handled in switch sendpacket.c: In function ‘sendpacket_open_pf’: sendpacket.c:624: warning: pointer targets in passing argument 2 of ‘get_iface_index’ differ in signedness sendpacket.c: In function ‘get_iface_index’: sendpacket.c:703: warning: pointer targets in passing argument 2 of ‘strlcpy’ differ in signedness sendpacket.c: In function ‘sendpacket_open_pf’: sendpacket.c:659: warning: ‘sp’ may be used uninitialized in this function mac.c: In function ‘macinstring’: mac.c:123: warning: ‘tok’ may be used uninitialized in this function mac.c: In function ‘dualmac2hex’: mac.c:83: warning: ‘tok’ may be used uninitialized in this function interface.c: In function ‘get_interface’: interface.c:72: warning: return discards qualifiers from pointer target type tcpdump.c: In function ‘tcpdump_print’: tcpdump.c:93: warning: implicit declaration of function ‘exit’ tcpdump.c:93: warning: incompatible implicit declaration of built-in function ‘exit’ tcpdump.c:96: warning: incompatible implicit declaration of built-in function ‘exit’ tcpdump.c: In function ‘tcpdump_open’: tcpdump.c:167: warning: incompatible implicit declaration of built-in function ‘exit’ tcpdump.c:190: warning: incompatible implicit declaration of built-in function ‘exit’ tcpdump.c:194: warning: incompatible implicit declaration of built-in function ‘exit’ tcpdump.c:198: warning: incompatible implicit declaration of built-in function ‘exit’ tcpdump.c:238: warning: incompatible implicit declaration of built-in function ‘exit’ tcpdump.c:245: warning: incompatible implicit declaration of built-in function ‘exit’ tcpdump.c:252: warning: incompatible implicit declaration of built-in function ‘exit’ tcpdump.c: In function ‘tcpdump_close’: tcpdump.c:278: warning: incompatible implicit declaration of built-in function ‘exit’ parse_args.c: In function ‘tcpedit_post_args’: parse_args.c:63: warning: initialization from incompatible pointer type edit_packet.c: In function ‘randomize_ipv4’: edit_packet.c:118: warning: unused variable ‘dstip’ edit_packet.c:118: warning: unused variable ‘srcip’ ./plugins/dlt_user/user.c: In function ‘dlt_user_parse_opts’: ./plugins/dlt_user/user.c:188: warning: initialization from incompatible pointer type ./plugins/dlt_user/user.c: In function ‘dlt_user_encode’: ./plugins/dlt_user/user.c:247: warning: ‘l2len’ may be used uninitialized in this function tcpreplay_opts.c: In function ‘doUsageOpt’: tcpreplay_opts.c:897: warning: unused parameter ‘pOptions’ tcpreplay_opts.c:898: warning: unused parameter ‘pOptDesc’ tcpreplay_opts.c: In function ‘doOptListnics’: tcpreplay_opts.c:966: warning: unused parameter ‘pOptions’ tcpreplay_opts.c:966: warning: unused parameter ‘pOptDesc’ tcpreplay_opts.c: In function ‘doOptPid’: tcpreplay_opts.c:1148: warning: unused parameter ‘pOptions’ tcpreplay_opts.c:1148: warning: unused parameter ‘pOptDesc’ tcpreplay_opts.c: In function ‘doOptVersion’: tcpreplay_opts.c:1161: warning: unused parameter ‘pOptions’ tcpreplay_opts.c:1161: warning: unused parameter ‘pOptDesc’ tcpreplay_opts.c: In function ‘doOptLess_Help’: tcpreplay_opts.c:1211: warning: unused parameter ‘pOptions’ tcpreplay_opts.c:1211: warning: unused parameter ‘pOptDesc’ send_packets.c: In function ‘do_sleep’: send_packets.c:336: warning: unused variable ‘pps_multi’ signal_handler.c: In function ‘suspend_handler’: signal_handler.c:91: warning: implicit declaration of function ‘exit’ signal_handler.c:91: warning: incompatible implicit declaration of built-in function ‘exit’ signal_handler.c: In function ‘continue_handler’: signal_handler.c:111: warning: incompatible implicit declaration of built-in function ‘exit’ tcpreplay.c: In function ‘post_args’: tcpreplay.c:282: warning: unused variable ‘gtod’ sleep.c: In function ‘ioport_sleep_init’: sleep.c:65: warning: implicit declaration of function ‘exit’ sleep.c:65: warning: incompatible implicit declaration of built-in function ‘exit’ sleep.c: In function ‘ioport_sleep’: sleep.c:99: warning: incompatible implicit declaration of built-in function ‘exit’ sleep.c:70: warning: unused parameter ‘nap’ tcpprep_opts.c: In function ‘doUsageOpt’: tcpprep_opts.c:920: warning: unused parameter ‘pOptions’ tcpprep_opts.c:921: warning: unused parameter ‘pOptDesc’ tcpprep_opts.c: In function ‘doOptAuto’: tcpprep_opts.c:988: warning: unused parameter ‘pOptions’ tcpprep_opts.c:988: warning: unused parameter ‘pOptDesc’ tcpprep_opts.c: In function ‘doOptCidr’: tcpprep_opts.c:1018: warning: unused parameter ‘pOptions’ tcpprep_opts.c:1018: warning: unused parameter ‘pOptDesc’ tcpprep_opts.c: In function ‘doOptRegex’: tcpprep_opts.c:1035: warning: unused parameter ‘pOptions’ tcpprep_opts.c:1035: warning: unused parameter ‘pOptDesc’ tcpprep_opts.c: In function ‘doOptPort’: tcpprep_opts.c:1056: warning: unused parameter ‘pOptions’ tcpprep_opts.c:1056: warning: unused parameter ‘pOptDesc’ tcpprep_opts.c: In function ‘doOptMac’: tcpprep_opts.c:1069: warning: unused parameter ‘pOptions’ tcpprep_opts.c:1069: warning: unused parameter ‘pOptDesc’ tcpprep_opts.c: In function ‘doOptComment’: tcpprep_opts.c:1090: warning: format ‘%d’ expects type ‘int’, but argument 3 has type ‘size_t’ tcpprep_opts.c:1084: warning: unused parameter ‘pOptions’ tcpprep_opts.c:1084: warning: unused parameter ‘pOptDesc’ tcpprep_opts.c: In function ‘doOptNo_Arg_Comment’: tcpprep_opts.c:1104: warning: unused parameter ‘pOptions’ tcpprep_opts.c:1104: warning: unused parameter ‘pOptDesc’ tcpprep_opts.c: In function ‘doOptInclude’: tcpprep_opts.c:1116: warning: unused parameter ‘pOptions’ tcpprep_opts.c:1116: warning: unused parameter ‘pOptDesc’ tcpprep_opts.c: In function ‘doOptExclude’: tcpprep_opts.c:1137: warning: unused parameter ‘pOptions’ tcpprep_opts.c:1137: warning: unused parameter ‘pOptDesc’ tcpprep_opts.c: In function ‘doOptServices’: tcpprep_opts.c:1158: warning: unused parameter ‘pOptions’ tcpprep_opts.c:1158: warning: unused parameter ‘pOptDesc’ tcpprep_opts.c: In function ‘doOptNonip’: tcpprep_opts.c:1170: warning: unused parameter ‘pOptions’ tcpprep_opts.c:1170: warning: unused parameter ‘pOptDesc’ tcpprep_opts.c: In function ‘doOptVersion’: tcpprep_opts.c:1293: warning: unused parameter ‘pOptions’ tcpprep_opts.c:1293: warning: unused parameter ‘pOptDesc’ tcpprep_opts.c: In function ‘doOptLess_Help’: tcpprep_opts.c:1333: warning: unused parameter ‘pOptions’ tcpprep_opts.c:1333: warning: unused parameter ‘pOptDesc’ tcpprep.c: In function ‘process_raw_packets’: tcpprep.c:400: warning: implicit declaration of function ‘add_tree_first’ tree.c:654: warning: ‘tree_print’ defined but not used tcprewrite_opts.c: In function ‘doUsageOpt’: tcprewrite_opts.c:1158: warning: unused parameter ‘pOptions’ tcprewrite_opts.c:1159: warning: unused parameter ‘pOptDesc’ tcprewrite_opts.c: In function ‘doOptCachefile’: tcprewrite_opts.c:1446: warning: unused parameter ‘pOptions’ tcprewrite_opts.c:1446: warning: unused parameter ‘pOptDesc’ tcprewrite_opts.c: In function ‘doOptVersion’: tcprewrite_opts.c:1460: warning: unused parameter ‘pOptions’ tcprewrite_opts.c:1460: warning: unused parameter ‘pOptDesc’ tcprewrite_opts.c: In function ‘doOptLess_Help’: tcprewrite_opts.c:1505: warning: unused parameter ‘pOptions’ tcprewrite_opts.c:1505: warning: unused parameter ‘pOptDesc’ tcprewrite.c: In function ‘rewrite_packets’: tcprewrite.c:235: warning: unused variable ‘i’ tcprewrite.c:235: warning: unused variable ‘frag_len’ tcpbridge_opts.c: In function ‘doUsageOpt’: tcpbridge_opts.c:1184: warning: unused parameter ‘pOptions’ tcpbridge_opts.c:1185: warning: unused parameter ‘pOptDesc’ tcpbridge_opts.c: In function ‘doOptInclude’: tcpbridge_opts.c:1527: warning: unused parameter ‘pOptions’ tcpbridge_opts.c:1527: warning: unused parameter ‘pOptDesc’ tcpbridge_opts.c: In function ‘doOptExclude’: tcpbridge_opts.c:1548: warning: unused parameter ‘pOptions’ tcpbridge_opts.c:1548: warning: unused parameter ‘pOptDesc’ tcpbridge_opts.c: In function ‘doOptPid’: tcpbridge_opts.c:1569: warning: unused parameter ‘pOptions’ tcpbridge_opts.c:1569: warning: unused parameter ‘pOptDesc’ tcpbridge_opts.c: In function ‘doOptVersion’: tcpbridge_opts.c:1582: warning: unused parameter ‘pOptions’ tcpbridge_opts.c:1582: warning: unused parameter ‘pOptDesc’ tcpbridge_opts.c: In function ‘doOptLess_Help’: tcpbridge_opts.c:1621: warning: unused parameter ‘pOptions’ tcpbridge_opts.c:1621: warning: unused parameter ‘pOptDesc’ tcpbridge.c: In function ‘post_args’: tcpbridge.c:207: warning: initialization from incompatible pointer type tcpbridge.c:225: warning: too many arguments for format tcpbridge.c:227: warning: assignment from incompatible pointer type tcpbridge.c:247: warning: too many arguments for format tcpbridge.c:249: warning: assignment from incompatible pointer type send_packets.c: In function ‘do_sleep’: send_packets.c:336: warning: unused variable ‘pps_multi’ sleep.c: In function ‘ioport_sleep_init’: sleep.c:65: warning: implicit declaration of function ‘exit’ sleep.c:65: warning: incompatible implicit declaration of built-in function ‘exit’ sleep.c: In function ‘ioport_sleep’: sleep.c:99: warning: incompatible implicit declaration of built-in function ‘exit’ sleep.c:70: warning: unused parameter ‘nap’ |
|
From: Abdelrazak Y. <you...@gm...> - 2009-01-07 07:14:49
|
Aaron Turner wrote: [snip about CMake] > 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. :( > No, MSVC project support is fully supported with CMake. The generated project are native and you can use the integrated debugger out of the box. Things are different with Scons as the generated project are not native. I guess Wireshark main problem is that GTK has not been fully ported to MSVC and they are forced to use a mix between Makefile and CMake; just a guess. >>> 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. :) It was not even holidays for me as this is a new job :-( But the point about piles of work is true nevertheless :-) > 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. > Well, I don't really understand what you are saying here... Maybe it didn't show up previously but, just to warn you, I am new to network programming and to network in general so I should have said "I'll for sure have questions". > 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. > OK, hopefully I'll have a working demo by then. We'll then decide how/where to host the project. Abdel. |
|
From: Aaron T. <syn...@gm...> - 2009-01-07 18:17:35
|
On Tue, Jan 6, 2009 at 11:14 PM, Abdelrazak Younes <you...@gm...> wrote: > Aaron Turner wrote: > > [snip about CMake] >> 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. :( >> > > No, MSVC project support is fully supported with CMake. The generated > project are native and you can use the integrated debugger out of the > box. Things are different with Scons as the generated project are not > native. > I guess Wireshark main problem is that GTK has not been fully ported to > MSVC and they are forced to use a mix between Makefile and CMake; just a > guess. That's good news... What I read must of been out of date or maybe I was just confused. [snip] >> 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. >> > > Well, I don't really understand what you are saying here... Maybe it > didn't show up previously but, just to warn you, I am new to network > programming and to network in general so I should have said "I'll for > sure have questions". No problem, I'd be more then happy to answer any questions you might have. If you have a lot of questions it would probably best for us to set a time to meet up on IRC, AIM, Skype or whatever. That way when my answer only leaves you with more questions you won't have to wait 24 hours for a response. :) >> 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. >> > > OK, hopefully I'll have a working demo by then. A working demo would be awesome. In a perfect world, I'll have a feel for what it will take to make tcpreplay run natively under Windows and we can make a decision on API vs. config file. > We'll then decide how/where to host the project. Ideally, I'd like to host it on the tcpreplay site with the rest of the code so we can have unified source control, ticketing, etc. I'd be more then happy to give you svn access, just send me the output of: htpasswd -sn <your username> (htpasswd ships with the apache webserver) You can register your own account in Trac for the tcpreplay site- let me know when you do so and I'll grant you some extra rights. 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 |
|
From: Aaron T. <syn...@gm...> - 2009-01-05 01:16:14
|
Never mind... tracked it down to a bug in my code. :) On Fri, Jan 2, 2009 at 11:51 AM, Aaron Turner <syn...@gm...> wrote: > Quick question: > > if you compile without --enable-debug on 4.3.3, and run (as root) > 'make test' do you get a bunch of errors (exit code 255) or passes? > Under OSX's 4.2 (which I just tried) it works just find under > --enable-debug but fails horribly without. Strange. > > Thanks, > Aaron > > On Fri, Jan 2, 2009 at 9:36 AM, Aaron Turner <syn...@gm...> wrote: >> Glad that got things working for you. I was suggesting IRC because if >> that didn't solve your problem, then you've got a problem I've never >> seen and I figured it would be easier to work it out over IRC then >> email. Generally speaking either works. >> >> Anyways, thanks for the warnings- I'm still using gcc 4.0 for the most >> part and so I don't get warnings except those in the *_opts.c files. >> >> -Aaron >> >> On Fri, Jan 2, 2009 at 2:20 AM, Abdelrazak Younes >> <you...@gm...> wrote: >>> Aaron Turner wrote: >>>> What I would recommend is follow the directions here: >>>> http://tcpreplay.synfin.net/trac/wiki/manual#GettingTcpreplayInstalled >>>> >>>> Specifically the part about using --disable-local-libopts and >>>> --disable-libopts-install. >>>> >>>> This will cause tcpreplay to link against your system version of >>>> autogen/autoopts which was used to generate the src/*_opts.[ch] files >>>> when you run make (they're not in SVN since they're generated source >>>> files, but they're included in the tarballs). >>>> >>> >>> OK, I did that and it compiled fine thanks. I had a number of warnings >>> that I pasted below just in case you are interested in having a look. >>> This is with gcc 4.3.3. >>> >>>> If that doesn't work, i'll be happy to work with you on irc >>>> (#tcpreplay on freenode). >>>> >>> >>> I have to admit I have never used irc. For LyX development we >>> communicate exclusively on the development mailing list. But I can try >>> if that's your preferred medium. >>> >>> Thanks, >>> Abdel. >> > > > > -- > 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 > -- 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 |
|
From: Abdelrazak Y. <you...@gm...> - 2009-01-05 09:00:22
|
Aaron Turner wrote: > Never mind... tracked it down to a bug in my code. :) > I was about to try :-) Abdel. |
|
From: Aaron T. <syn...@gm...> - 2009-01-05 20:16:06
|
On Mon, Jan 5, 2009 at 1:31 AM, Abdelrazak Younes <you...@gm...> 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 |
|
From: Aaron T. <syn...@gm...> - 2009-01-06 16:35:55
|
On Tue, Jan 6, 2009 at 5:09 AM, Abdelrazak Younes
<you...@gm...> 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
|
