Wireshark-dev: Re: [Wireshark-dev] [GSoC] Packet Editor and Viewer
From: Edwin Abraham <[email protected]>
Date: Thu, 25 Apr 2013 11:58:36 +0530
I will be submitting the proposal on google's gsoc site in a day's time.
I wanted to know if the mentors would wants to review it before I submit it?

@Guy Harris
I would like to know if you require any more clarification on my Idea and also whether you will be willing to review the proposal before I submit it.

Also I would like to start the development on this immediately. Any more guidance is appreciated.

On Fri, Apr 19, 2013 at 3:50 AM, Edwin Abraham <[email protected]> wrote:
Thanks for clearing that up about editcap. Maybe the interactiveness for the editcap CLI can be taken from this UI.

Okay lets say that there are a group packets that exist in a huge capture file. And the data needs to be retrieved, stored and interpreted.
So the capture is opened in Packet Editor. The filter option in the UI can help pull the packets to be defined (either the filter can be defined by the default filter or by a packet editor based filter UI ). Once the filtered packets are pulled, the UI gets populated with the grid of data that is all collapsed till the last payload which will be displayed in the requested data format (HEX/BIN/DEC/ASCII) . And the fields used to filter the packets will be highlighted.


After clicking on a single packet the UI is opened with the all the fields till data payload. Now edit options will be available. Now the data field is alone opened alone and is displayed withe edit options available on the top of the data grid. The data grid can be edited then and there it self just like a text editor.  Bit sometimes you need to have a operation conducted on that.This UI will help select the data and name the data selection. Multiple data can be marked and used for manipulation.

This data can be manipulated in the required manner by defining a simple flowchart UI, (essentially a program the user define). Now the flow-chart UI is opened with fixed set of functions to  define the action for the named selection. The flow-chart will have exits to account for batch edits. So once the action is defined in the flow-chart it can be ported for all the packets in the UI. The selections can be made for each field and named accordingly so that it can be properly referred to all the packets. The Flow-chart UI can have options to access to write files.
This entire process will also include saving to packets and saving the capture. If live capture then setup listener to apply the change dynamically. Simple edits to the data like shifts, time change or edit functions based on editcap can be done without calling the FlowChart UI. But that will give a graphical programming experience to the user.

Now addressing manipulating capture files. We can pull the a 2-D grid of multiple packet editing views to represent multiple capture files. Then the operations can be applied by zooming into each view separately. This will give more concise control over the Merge, Split and Export options.

To clear up the idea I suggest a active chat so that you can suggest the issues with my explanations. The google drive Drawing mode can act as simple whiteboard as it supports active changes.

On Thu, Apr 18, 2013 at 10:30 PM, Guy Harris <[email protected]> wrote:

On Apr 15, 2013, at 1:57 PM, Edwin Abraham <[email protected]> wrote:

> I agree on the confusion. The initial thought when I saw the project details on the Wireshark GSoC page was that a platform to design dissectors based on existing data.

That's an interesting idea, but that's not any of the current GSoC proposals.  Perhaps it should be.

> My thought about the Packet Editor environment was to have a UI that can be used for multiple functions. Packet editing, Creating Filter/Dissectors, Tools making listener. The main function would be to extend the editcap capabilities to the GUI.

...which means deleting entire packets (-A and -B; -d, -D, and -w; and the packet range arguments and -r), tweaking time stamps (-S and -t), removing data from all or specified packets (-C and -s).

The randomly-trash-data-in-the-packet function is there for fuzz-testing, and probably doesn't need to be in Wireshark.

The other functions are for splitting capture files up; that would probably be done in a function under the File menu in an Export function; it's not an interactive editing function.

The only editcap functions that involve editing packet data are the ones that chop data from the beginning or end of the packet; there's nothing that resembles the current (not configured in by default) packet editor UI.

> After filtering out and selecting the required packets, they are opened in the Packet Editor UI. The packets can be a capture file or a capturing device

"A capturing device" is, in effect, a capture file; if you're doing, or have done, a live capture, Wireshark has a capture file open that contains the captured packets.

> but the filter has to narrow down the packet editing.
> The UI will have three sets of toolbar and options (editcap,dissector,listener) to manipulate the packet.
> There will also exist a viewing tools to change how the selection of packets are percieved. Like data can be represented as HEX/BIN/ASCII with help of toggle switches.

To which data are you referring?  A particular field?

> Below is a rough idea of how the UI can look like.

Static views of a UI don't always indicate very much.

Could you describe a typical task that would be done with the UI, by walking through the operations that would be done with the UI elements?
Sent via:    Wireshark-dev mailing list <[email protected]>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:[email protected]?subject=unsubscribe

Edwin Abraham,
BITS Pilani Goa Campus

Edwin Abraham,
BITS Pilani Goa Campus