Am 07.02.2011 21:08, schrieb Sam Roberts:
On Mon, Feb 7, 2011 at 11:36 AM, Gregory Seidman
<gsslist+wireshark@xxxxxxxxxxxxxxxxxx> wrote:
Ah, interesting. Thanks for the info on netdude. I clearly disagree with
you in that I think Wireshark (the project, though not necessarily the
existing GUI) is the best possible place for packet editing.
You're totally right. There exist all the dissectors in Wireshark. And
there exists a tool
called editcap in the Wireshark-suite, which only supports fundamental
editing.
I should have mentioned this in my last post.
Well all the things which Sam describes looks like a lot of work...
And to maintain a second co-existing GUI seems to be hard, too. So, in
the moment
I'm not really sure what the best way looks like. Furthermore I think it
is a basic design
question whether to support editing or not. In my opinion there should
be a desicion
by the core developers.
Modifying packets would involve significantly more work on the part of
the dissector developers, and it can be very difficult to even know
what it means to "modify" a packets.
I've wrestled with this a bunch, including the poverty of good packet
construction toolkits. I'm currently maintaining libnet (NOT the
author), and also work for a company (Wurldtech) that generates bad
protocol traffic to test implementations. Here's some stuff to think
about.
Right now, wireshark has C code that decodes packets, building an
in-memory tree for the UI (or tshark) that describes the packet.
Going the other way, since the tree knows what bytes are associated
with values, might not seem such a big deal, but editing a packet has
several possible, but very different, outcomes.
One is the packet is still somewhat valid. This involves recursing
back down the packet tree, correcting encapsulating lengths and
checksums as you go. Also, perhaps correcting other linking
elements (you change a function ID in a packet, but the function ID is
also present in an encapsulating layer, should it be changed in both
places?).
The other is the packet is being "fuzzed", the result is intended to
be invalid. This is simpler, you just change one thing. But, its
rarely so simple, even when generating test data. Many protocol
processors will discard any data with bad checksums, so you don't end
up actually getting your test data processed unless checksums are
recalculated. So some kind of semi-validity is still required.
libnet's API allows rewriting a layer of a protocol in-place, but
isn't good at it, can easily result in (unintentionally) invalid
packets, and also was subtle enough that doing so could often cause
libnet to segfault. Tough going.
The effect of all this is there is very little choice or discretion
involved in packet decoding, what wireshark does. Somebody else made
the packet, you are just displaying it (though you might run into some
difficulties if the packet is invalid, and wireshark does have the
occaisonal puke-up on bad packets).
Going the other way, encoding packets, there are HUGE amounts of
discretion and choice involved, and once you get into the realm of
modifying packets, possibly involving generating non-compliant
packets, the choice explodes to the point that I can's see how a
general purpuse GUI would ever do a good job of it.
Cheers,
Sam
___________________________________________________________________________
Sent via: Wireshark-dev mailing list<wireshark-dev@xxxxxxxxxxxxx>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe