Wireshark · Wireshark-dev: Re: [Wireshark-dev] GSoc Idea clarification

[Guy Harris <guy@xxxxxxxxxxxx>]

On Apr 12, 2013, at 11:10 PM, jai gupta <sayhellotojai@xxxxxxxxx> wrote:

> Hi,
> 
> I am Jai Gupta,  a computer science student at Indian Institute of Technology, Kharagpur, INDIA. Interested in contributing to wireshark this summer being a part of gsoc 2013, I went through the ideas listed on this link. http://wiki.wireshark.org/GSoC2013.
> 
> I was interested in the porting Wireshark to Android. As we need to build a JSON message based interface to the existing core library, I would like to know if the existing GUI and core project are seperate. and does the core provide a  interface for the GUI or is the GUI built upon parsing the cli interface and passing commands in the background to the shell?

Currently, Wireshark consists of:

	a very small utility library containing stuff used by more than one of the other pieces;

	a medium-sized library (libwiretap) for reading capture files;

	a really big library (libwireshark) that contains the dissectors and the infrastructure code they use;

	a set of plugins that can be loaded by libwireshark to perform dissection, do statistics tapping, and support capture file formats;

	a set of programs that use one or more of those libraries.

Wireshark, which existed before TShark (well, Ethereal existed before Tethereal; the name change occurred after Tethereal was created), is one of those programs; it implements a GUI that uses libwireshark to do dissection and libwiretap to read capture files.

TShark is another one of those programs; it implements a command-line interface that uses libwireshark to do dissection and libwiretap to read capture files.

Wireshark doesn't parse the output of TShark (and never did, given that Ethereal existed before Tethereal existed); they both use the results of libwireshark.

> How do we aim to build the JSON interface, will it parse the result from cli or there exists a core API whose results we need to convert to JSON?

There exists a core API - libwireshark.

> Wont it be a good idea to develop a web interface instead on the JSON interface and just display it in a webkit

(I assume you mean "instead *of* the JSON interface" here, i.e. don't do this with a native app *and* don't do this with JSONshark.)

What do you mean by "web interface" here?  Do you mean something such as Hethereal:

	http://www.wireshark.org/lists/ethereal-dev/200103/msg00053.html

or Cloudshark:

	http://www.cloudshark.org

or what pcapr:

	http://www.pcapr.net/home

uses to display packets, i.e. a "thin client" version of Wireshark, with all the dissection done on the server, and some amount of presentation/UI done on the client (e.g., with the client-side portion of the code written in Javascript)?

If so, does "display it in a webkit" mean "write yet another damn "app" that's just a cheesy browser replacement"?  If so, well, this sums up a *lot* of apps that are just front ends for Web sites:

	http://xkcd.com/1174/

If we're going to build "thin client" version of Wireshark, I'd prefer to make it generate HTML+Javascript that can be handled by any reasonable modern browser, even on smartphones and tablets, and avoid writing a client-side app if we possibly can.

If, however, we plan to have more processing than just UI done on the client, then JSON might hide less of the underlying packet data than displayable HTML, making it easier to build parts of the app that do statistics.  That's a different split from the "Web Wireshark" split, and might more easily allow stuff that involves significant processing, such as statistics, to be done.

> rather building an app which uses the android API?

To quote Gerald Combs' comment on that item:

	I think the uses cases are different and both are valid. JSONshark would separate the capture source from display, which is a radical shift from our current architecture. This would make it easier for a home user to see what's happening on his or her router for example. An Android port would let you run Wireshark on your phone or tablet, and thanks to Mike Kershaw you can now do local 802.11 capture with an RTL 8187 adapter.