mailing list archives
Re: GSoc Idea clarification
From: Guy Harris <guy () alum mit edu>
Date: Sat, 13 Apr 2013 17:25:37 -0700
On Apr 12, 2013, at 11:10 PM, jai gupta <sayhellotojai () gmail com> wrote:
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.
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
What do you mean by "web interface" here? Do you mean something such as Hethereal:
or what pcapr:
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
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:
handled by any reasonable modern browser, even on smartphones and tablets, and avoid writing a client-side app if we
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.
Sent via: Wireshark-dev mailing list <wireshark-dev () wireshark org>
mailto:wireshark-dev-request () wireshark org?subject=unsubscribe