Hi again, On Wed, May 21, 2008 at 7:25 PM, Aaron Turner <[EMAIL PROTECTED]> wrote: > On Wed, May 21, 2008 at 10:14 AM, Piers O'Hanlon <[EMAIL PROTECTED]> wrote: >> I guess arbitrary adjustments to fields/bytes (maybe just byte counts >> within a packet would be nice) - > > For example???? Not trying to be difficult, but I'm trying to > understand the scope of the problem. Perhaps more importantly, are > we talking L2-L4 headers or TCP stream payload data? Do you need the > payload stream reassembled (TCP segments, IP frags)? > > Also, what do you mean by "byte counts within a packet"? Not sure how > that is different from the pad/truncate functionality tcprewrite > already has. > Sorry I didn't explain clearly - I meant that for example - I would like to be able to replace the 32nd byte in the packet with an arbitrary number - this could dependent on the value of another byte (or sequence). Handier still would be if there was a way (like tshark allows for display) to access particular bytes within predefined payload type by name (as opposed to byte counting to the right byte within a packet). I guess checksum would need recalculating. E.g if I've got a bunch of RTP packets stored and I want to, say tweak some bits in the header or payload.
>> Maybe it might be possible to utilise >> wireshark's packet parsers/decoders - then one can build on their library >> of formats. > > That's something I've though about. Historically, the wireshark > developers have discouraged that because the API isn't considered > stable yet. Maybe with the 1.0 release that's changed. Having all > the decoders sounds great, but just how often do you want to go in and > edit a field tcprewrite doesn't already support? > I guess the advantage is having easy access to the application level fields which tcprewrite doesn't currently support. >> If some of this is possible then let me know - I may not have fully read all >> the docs. > > Well nothing is impossible... it's just a question of time/effort. > Making the fragroute code into a library that I could use in > tcprewrite was 10ish hours of effort. Very doable for a single > developer working part time. The wireshark code base is MUCH larger > and constantly changing- that makes integration much more challenging > for me. > Sure - I can see that. May be there's a way to plug in their decoders in without making your codebase too dependent on their changes - but if as you say their API changes often then it may be tricky. > Anyways, right now my big concern with this whole feature is that it's > really easy to miss the mark (not provide the functionality people > actually need and provide functionality nobody cares about) and at the > same time eat a lot of my time which could be better spent on other > features. And of course, if there are other tools (like Scapy?) which > can do the same thing, I'm not sure what the real value is of me > reinventing the wheel. > True. Though manipulating traces for playback isn't so available. > Like one feature I'm thinking about is a graphical wizard (most likely > a webapp since I don't know QT/GTK/Fox or any other widget library and > my UI skills frankly suck ass) which basically walks people through a > bunch of questions and spits out a config file for > tcpprep/tcprewrite/tcpreplay. Based on most of the questions on this > list, I think such a tool would be really helpful for a lot of people > and make tcpreplay useful to a wider userbase. > Maybe - I guess the kind of people who want to replay tcpdump streams tend to know a bit more about what they're doing than the average user. Thanks again, Piers. > Anyways, thanks for the feedback Piers! > > -- > 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 > ------------------------------------------------------------------------- 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
