Wireshark-dev: [Wireshark-dev] D-Bus support

From: frederic heem <frederic.heem@xxxxxxxxx>
Date: Wed, 25 Oct 2006 18:37:32 +0200
Hi,
D-Bus support has been adding to wireshark.
For those who are interested to know more about this feature, a README.dbus 
has been written. 
Any comments will be appreciated
Cheers,
Frederic Heem



______________________________________________________________________________

--- NOTICE ---

CONFIDENTIALITY - This  email  and  any  attachments  are confidential and are
intended  for  the  addressee  only.   If  you  have  received this message by
mistake,  please  contact us immediately and then delete the message from your
system.  You  must  not copy, distribute, disclose or act upon the contents of
this email. Thank you.

PERSONAL DATA PROTECTION  (Law  by  Decree  30.06.2003  n. 196) - Personal and
corporate  data  submitted  will  be used in a correct, transparent and lawful
manner. The data collected will be processed in paper or computerized form for
the performance of contractual  and  lawful  obligations  as  well  as for the
effective management of business relationship. Data may be disclosed, in Italy
or abroad, for the purpose above mentioned to third  parties  which  cooperate
with Telsey, agents, banks, factoring companies,  credit recovering companies,
credit  insurance  companies,  professional  and  consultants,  and   shipping
companies. In relation to the same purposes, data  may  be  processed  by  the
following  classes  of  executors  or  processors:  management; administration
department; logistics  and  purchase  department; sales department; post sales
department quality department; R&D department; IT department; legal department.
The  data  processor  is  Telsey S.p.A.  The data subject may exercise all the
rights set forth in art. 7 of Law by Decree 30.06.2003  n. 196 as reported  in
in the following link http://www.telsey.it/privacy.jsp. 

______________________________________________________________________________
798t8RfNa6Dl8Ilf
Controlling wireshark through D-Bus 

Purpose:
The purpose is to allow external applications to easily start and stop captures, as well as setting all necessary parameters such as the network interface and the capture filter.
In the past, the only way to control wireshark was to spawn a new process. The biggest problem with this method is that commication between the application and wireshark is done through stdin, stdout and stderr, and (UNIX) signal. This Inter Process Communication is a text based, which imposes wireshark and external programs to write a lot a hand written code.
Addind a decent IPC like D-Bus into wireshark greatly improves how wireshark can be controlled.

Functionnality:
A contract describing the servive is given to external application, the xml file dbus/wireshark-dbus-server-idl.xml contains all possible actions that the wireshark service will offer to the client application. This file is equivalent of IDL files for Corba, and WSDL files for SOAP. 
An application can request any number of simultaneous captures to wireshark. Use the method "requestCapture" to request a capture name, then use this name to start, stop or set somne parameters.
Another nice feature is that remote captures will come "for free" as soon as D-Bus implements it.

Dependency:
Since wireshark is a glib based application, dbus-glib binding has been use to implement this feature.
However, the test application is written with the Qt toolkit, and is based on the QtTest library, this provides a nice framework for building unitest and system test application. Note that building the test application is optional but stronly recommended.

Here is a list of the needed software:
dbus 1.0 RC2
dbus-glib 0.74
Qt 4.2 (test only)
cmake 2.4 (build only)

Compilation:
Cmake is used to build the wireshark with DBus, D-Bus functionality is off by default, so set the cmake variables ENABLE_DBUS and ENABLE_DBUS_TEST to ON

Usage:
As root, use dumpcap with the command line option -d
[root@heefre ~]#dumcap -d
It will try to register to the D-Bus daemon but failed if "dumpcap -d" is already running.

Security implication:
D-Bus can be also be used to seperate concerns and improves security, dumpcap needs root priviliges but is only allowed to capture packets and saves them to a file. On the other hand, an application that requires packet capture do not need root privileges, the application can be the one that decodes packets, this operation is usally subject to crashed by injecting malformed packets, since decoding no longer needs root privileges, security is improved.
The dbus-daemon is responsible of allowing or denying capture to client, this method allows fine grained security control.

Known issues:
* When a client crashes, dumcap shall destroy all captures started by the application, 
* A bug in dbus_connection_get_unix_user prevents wireshark to retrieve the user id and group id of the application that has requested the capture, hence, it os not possible to chaneg the capture filename permission: https://bugs.freedesktop.org/show_bug.cgi?id=8381
* dbus-glib memory leaks and better NULL pointer error handling: https://bugs.freedesktop.org/show_bug.cgi?id=8350
* fix some libpcap uninitialized variables  https://sourceforge.net/tracker/?func=detail&atid=469577&aid=1552777&group_id=53067
* fix pcap_open_live timeout: https://sourceforge.net/tracker/?func=detail&atid=469579&aid=1576578&group_id=53067
* fix some libpcap crash due to stale pointer: https://sourceforge.net/tracker/?func=detail&atid=469577&aid=1584514&group_id=53067
* libpcap is not 100% thread safe: https://sourceforge.net/tracker/index.php?func=detail&aid=1534711&group_id=53067&atid=469577


QA:
Efforts has been been done to strive for high quality standard, that is using the right tool for the given problem
valgrind (www.valgrind.org) has been the best debugging tool so far. It has found so many bugs that would been very difficult to find without it.
Some work still has to be done in the area of static code analysis (splint, PCLint, coverty ...) and threading issues (helgrind, intel thread checker)

October 2006
Frederic Heem
frederic.heem@xxxxxxxxx