So with 3.3.0 out the door and no known bugs (yet), I've started to make plans for the next major release. Right now, the plan is extending tcprewrite with either a limited or full blown packet editing language. Before going down that path, I wanted to touch base with everyone and get a feel for if this is really where I should be spending my time. I've got a list of planned features/enhancements here:
http://tcpreplay.synfin.net/trac/report/10?sort=milestone&asc=1 If you see something missing, by all means open a feature request. If you see something more interesting/important to you, please speak up! If enough people say something else is more important (maybe the graphing feature in ticket #25) then I'll work on that first instead. There's also the question of what the packet editing language looks like. This is pretty important since this will be the method which you the users interact with the engine to edit packets. I've given it some thought, and the two ideas which seem to be the best to me are integrating a language like Lua (http://www.lua.org/) or coming up with a simple declarative packet editing format. Lua is interesting since it's designed to be embedded looks relatively simple and looks powerful enough to get the job done. Probably need to research things sufficiently to confirm it has all the necessary features we'd need to deal with both binary and text based protocols. Of course, there are other languages too: Ruby, Python, Perl, etc. I'll be honest, I hate Python so that's probably not going to happen, but I'm pretty fluent in both Ruby & Perl. Between the two I'd probably pick Ruby- but I'd have to research embedding Ruby in C (I've embedded C in Ruby before). Hopefully I can get some consensus on what language to use. The other option is using a simple declarative syntax to edit packets. This wouldn't be a full blown language and all the features would have to be backed by C code so it would be faster, but less powerful and harder to extend. It might look something like this: Packet 57: # packet to modify Offset: 89 # byte offset starting from start of packet Direction: C2S # direction of packet Type: IPv4 # type of field Encoding: big_endian # encoding of new value Value: 192.168.2.34 # optional new value One major advantage of going the Ruby/Lua route is that people would be able to write protocol decoders and make it easy to edit not just packets, but flows and sessions at the application layer. The declarative method would probably exclude that and basically require you to open up the pcap file in Wireshark and make edits manually on a packet by packet basis each as a stream of bytes. You might get simple control logic (if/then/else, loops, etc) with the declarative solution, but don't expect a whole lot. Understanding the needs of everyone and your willingness to deal with learning/using a real programming language like Lua or Ruby would be a big help making a decision. Anyways, those are my current thoughts... if you have any other ideas, thoughts or comments, please reply back to the list or email me privately. -- Aaron Turner http://synfin.net/ http://tcpreplay.synfin.net/ - Pcap editing & replay tools for Unix They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ Tcpreplay-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tcpreplay-users
