Sorry for the mess in the previous mail. Here is the link to the GUI jpeg
 
packet-editor-UI.jpg<https://docs.google.com/file/d/0BzQfAxVhGpq9S2RKWGxudExnQjQ/edit?ups=drive_web>



On Tue, Apr 16, 2013 at 2:27 AM, Edwin Abraham <edwin.abraha...@gmail.com>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. Then I extrapolated from that Idea to the Packet
> Editor.
>
> About the LUA code to run without restarting. We need to call init.lua
> again to re-load the scripts. But that may interfere with the existing lua
> based wireshark components. If we kill all captures and freeze the gui into
> a refresh, during the re-loading of the scripts, that should help. I am not
> quite sure of this. It may be better to reload the wslua machine itself.
>
> 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.
>
> 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 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. Then an edit tracker that highlights the edits to
> the packet can be enabled with a full range of customizable colours for
> each type of edit. The view will also have single packet view and multiple
> view. Each of the single packet will have ability to switch the selected
> data between HEX/BIN/ASCII/DEC. Whereas the Multiple Packet View will have
> a default data representation of HEX so that the view is compact.
>
> The Packet Editor part of the UI can have UI buttons for each of the
> editcap functionalities like changing the timestamp, simple shifts to the
> data, etc. Once the settings is applied for one packet it can be applied to
> all the remaining packets in the packet editor UI. With simple highlighting
> each of the changes can be seen so that when an edit is applied for the
> entire selection of packets the progress can be seen. When saving if we
> give option to store extra info about how the edit history looks like.
>
> While using Packet Editor the Dissector/Listener toolbar should be
> disabled when using the editcap based toolkit. This will avoid unnecessary
> bugs. The Dissector/Listener will use the LUA interpreter to create custom
> dissectors and listeners. The GUI will give more accessible methods to
> select and create the protocol-fields and specify the details of each of
> them. As the success of the simple Dissectors are tested we can even give
> the filters access to use the UI to make the filters and save them.
> Listener functionalities I will need to look a little more into them.
>
> Below is a rough idea of how the UI can look like.
>
>
>
> The difference between single view and multi-view is that it will have the
> grid-structure with collapsible protocol headers in a column view. Each
> data element can be given a option to be viewed as a different data type
> than the rest in a pop-up and then resize the grid to accommodate the
> change.
>
> Since the custom dissectors will take time to implement the dissector. It
> will be better to include a temp mode where the dissector can be applied to
> the packet in the gui not in the packet before actually creating the
> dissector.
>
> Though I am saying editcap when referring to the editor. I mean to use the
> functionalities. And then link the editcap to the gui later on.
>
>
>
>
> On Sun, Apr 14, 2013 at 10:15 PM, Guy Harris <g...@alum.mit.edu> wrote:
>
>>
>> On Apr 14, 2013, at 12:45 AM, Edwin Abraham <edwin.abraha...@gmail.com>
>> wrote:
>>
>> > Last Summer as a part of an internship at DRDO (Defense Research and
>> Development Organisation) I was asked to go through their custom networking
>> protocol. So that they could improve the protocol handling and how the
>> application handled. Since they needed a quick fix and I used LUA scripts
>> to write a custom dissector for them. They were happy with the result. But
>> the in the end I realized they wanted to open the packet edit the data
>> within wireshark, compare it with other protocols they were using.
>> >
>> > I agree with the fact there is a Packet Viewer but it’s not editable.
>> But if there is a UI where the packets can be manipulated by applying data
>> changes or designing a dissector with the existing packets.
>>
>> Unless I *completely* misunderstand what you're proposing, "a UI where
>> the packets can be manipulated by applying data changes" is a completely
>> separate item from "[a UI for] designing a dissector with the existing
>> packets".
>>
>> How do you envision the latter item working?  And would it be more useful
>> if you had a UI to design a dissector *regardless* of whether you have a
>> capture file open with packets for that protocol, even if it has some
>> additional features that let you use existing packets for the protocol?
>>
>> > LUA is powerful and if the UI is setup to create the dissector without
>> using an IDE or  at least eventually. If the reboot is given from within
>> the UI we can resume the Packet Editor session when wireshark restarts.
>>
>> And if there's no need to *have* a reboot to use a new piece of Lua code,
>> that would be even better - you wouldn't *need* to resume the session.
>>
>> > I was thinking the Packet Editor should be able to display the packet
>> data to the user in the mode he desires. Like if the user wants to see the
>> packet in hex, then a specific part in decimal. Or to have the headers
>> applied and not applied on the packet. In the following is a rough idea of
>> what I mean.
>>
>>         ...
>>
>> > Initially when a packet is opened it is already filtered by the headers
>> IP,UDP,etc. This editor can display the data in a way comfortable to add
>> custom headers (using dissectors) and temporarily apply and see the
>> payload. Once the packet is modified to user requirement, the user can
>> apply listeners to send the required data to the applications to analyse
>> the data.
>> >
>> > When I mentioned that the editor can exist on its own I meant the UI
>> can be used wherever in wireshark to view packets like when designing
>> dissectors, applying filter, or any kind of packet manipulation.
>>
>> You seem to be talking about changing the way packets are *displayed*.
>>  That's not really an "editor" function, that's a "viewer" function; the
>> Packet Editor (GUI) item in the Wireshark GSoC page says "It would be
>> useful to be able to edit packet contents and to save edited packets back
>> to disk."
>>
>> What you're describing could be interesting (although you need to
>> describe it more clearly, for example by giving some examples of what the
>> UI might look like and what operations it supports), but it doesn't sound
>> as if it's a "packet editor", it sounds more like a "dissector editor".
>>  I.e., it sounds as if you're describing something that lets you change the
>> way packet data is displayed, not something that lets you actually change
>> the data *in* the packet.
>>
>>
>> ___________________________________________________________________________
>> Sent via:    Wireshark-dev mailing list <wireshark-dev@wireshark.org>
>> Archives:    http://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>>              mailto:wireshark-dev-requ...@wireshark.org
>> ?subject=unsubscribe
>>
>
>
>
> --
> Edwin Abraham,
> BITS Pilani Goa Campus
>



-- 
Edwin Abraham,
BITS Pilani Goa Campus
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Reply via email to