Well that completely failed to generate any discussion.... I'll take it as nobody really cares about more flexible packet editing? Anyways, I'm not going to implement this feature if I can't get some feedback from people on the list... it's just too easy to end up creating something too simplistic or complex and making it useless for the majority of the users.
-Aaron On Mon, May 5, 2008 at 10:28 AM, Aaron Turner <[EMAIL PROTECTED]> wrote: > 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: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Tcpreplay-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tcpreplay-users Support Information: http://tcpreplay.synfin.net/trac/wiki/Support
