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