201 201

C.1.2. [Packet size limited during capture]... C.2. Packet Details Messages... C.2.1. [Response in frame: 123].. C.2.2. [Request in frame: 123]... C.2.3. [Time from request: 0.123 seconds]... C.2.4. [Stream setup by PROTOCOL (frame 123)].. D. Related command line tools... D.1. Introduction.... D.2. tshark: Terminal-based Wireshark... D.3. tcpdump: Capturing with tcpdump for viewing with Wireshark.. D.4. dumpcap: Capturing with dumpcap for viewing with Wireshark. D.5. capinfos: Print information about capture files.. D.6. rawshark: Dump and analyze network traffic.. D.7. editcap: Edit capture files... D.8. mergecap: Merging multiple capture files into one.. D.9. text2pcap: Converting ASCII hexdumps to network captures.. D.10. idl2wrs: Creating dissectors from CORBA IDL files.. D.10.1. What is it?... D.10.2. Why do this?... D.10.3. How to use idl2wrs... D.10.4. TODO... D.10.5. Limitations... D.10.6. Notes.... E. This Document's License (GPL)...

218 219

Preface

1. Foreword

Wireshark is one of those programs that many network managers would love to be able to use, but they are often prevented from getting what they would like from Wireshark because of the lack of documentation. This document is part of an effort by the Wireshark team to improve the usability of Wireshark. We hope that you find it useful, and look forward to your comments.
2. Who should read this document?
The intended audience of this book is anyone using Wireshark. This book will explain all the basics and also some of the advanced features that Wireshark provides. As Wireshark has become a very complex program since the early days, not every feature of Wireshark may be explained in this book. This book is not intended to explain network sniffing in general and it will not provide details about specific network protocols. A lot of useful information regarding these topics can be found at the Wireshark Wiki at http://wiki.wireshark.org By reading this book, you will learn how to install Wireshark, how to use the basic elements of the graphical user interface (such as the menu) and what's behind some of the advanced features that are not always obvious at first sight. It will hopefully guide you around some common problems that frequently appear for new (and sometimes even advanced) users of Wireshark.

3. Acknowledgements

The authors would like to thank the whole Wireshark team for their assistance. In particular, the authors would like to thank: Gerald Combs, for initiating the Wireshark project and funding to do this documentation. Guy Harris, for many helpful hints and a great deal of patience in reviewing this document. Gilbert Ramirez, for general encouragement and helpful hints along the way. The authors would also like to thank the following people for their helpful feedback on this document: Pat Eyler, for his suggestions on improving the example on generating a backtrace. Martin Regner, for his various suggestions and corrections. Graeme Hewson, for a lot of grammatical corrections. The authors would like to acknowledge those man page and README authors for the Wireshark project from who sections of this document borrow heavily: Scott Renfro from whose mergecap man page Section D.8, mergecap: Merging multiple capture files into one is derived. Ashok Narayanan from whose text2pcap man page Section D.9, text2pcap: Converting ASCII hexdumps to network captures is derived.

A number of errors can occur during the installation process. Some hints on solving these are provided here. If the configure stage fails, you will need to find out why. You can check the file config.log in the source directory to find out what failed. The last few lines of this file should help in determining the problem. The standard problems are that you do not have GTK+ on your system, or you do not have a recent enough version of GTK+. The configure will also fail if you do not have libpcap (at least the required include files) on your system. Another common problem is for the final compile and link stage to terminate with a complaint of: Output too long. This is likely to be caused by an antiquated sed (such as the one shipped with Solaris). Since sed is used by the libtool script to construct the final link command, this leads to mysterious
problems. This can be resolved by downloading a recent version of sed from http://directory.fsf.org/ project/sed/. If you cannot determine what the problems are, send an email to the wireshark-dev mailing list explaining your problem, and including the output from config.log and anything else you think is relevant, like a trace of the make stage.
2.7. Building from source under Windows
It is recommended to use the binary installer for Windows, until you want to start developing Wireshark on the Windows platform. For further information how to build Wireshark for Windows from the sources, have a look at the Developer's Guide on the Documentation Page. You may also want to have a look at the Development Wiki: http://wiki.wireshark.org/Development for the latest available development documentation.
2.8. Installing Wireshark under Windows
In this section we explore installing Wireshark under Windows from the binary packages.

2.8.1. Install Wireshark

You may acquire a binary installer of Wireshark named something like: wiresharkwinxx-1.7.x.exe. The Wireshark installer includes WinPcap, so you don't need to download and install two separate packages. Simply download the Wireshark installer from: http://www.wireshark.org/download.html and execute it. Beside the usual installer options like where to install the program, there are several optional components.
Tip: Just keep the defaults!
If you are unsure which settings to select, just keep the defaults.
2.8.1.1. "Choose Components" page
Wireshark Wireshark GTK - Wireshark is a GUI network protocol analyzer. TShark - TShark is a command-line based network protocol analyzer. Plugins / Extensions (for the Wireshark and TShark dissection engines): Dissector Plugins - Plugins with some extended dissections. Tree Statistics Plugins - Plugins with some extended statistics. Mate - Meta Analysis and Tracing Engine (experimental) - user configurable extension(s) of the display filter engine, see http://wiki.wireshark.org/Mate for details. SNMP MIBs - SNMP MIBs for a more detailed SNMP dissection. Tools (additional command line tools to work with capture files): Editcap - Editcap is a program that reads a capture file and writes some or all of the packets into another capture file.

This field is also where the current filter in effect is displayed. Expression. The middle button labeled "Add Expression." opens a dialog box that lets you edit a display filter from a list of protocol fields, described in Section 6.5, The "Filter Expression" dialog box Reset the current display filter and clears the edit area. Apply the current value in the edit area as the new display filter.

Clear Apply

Applying a display filter on large capture files might take quite a long time!
3.18. The "Packet List" pane
The packet list pane displays all the packets in the current capture file.
Figure 3.16. The "Packet List" pane
Each line in the packet list corresponds to one packet in the capture file. If you select a line in this pane, more details will be displayed in the "Packet Details" and "Packet Bytes" panes. While dissecting a packet, Wireshark will place information from the protocol dissectors into the columns. As higher level protocols might overwrite information from lower levels, you will typically see the information from the highest possible level only. For example, let's look at a packet containing TCP inside IP inside an Ethernet packet. The Ethernet dissector will write its data (such as the Ethernet addresses), the IP dissector will overwrite this by its own (such as the IP addresses), the TCP dissector will overwrite the IP information, and so on. There are a lot of different columns available. Which columns are displayed can be selected by preference settings, see Section 10.5, Preferences. The default columns will show: No. The number of the packet in the capture file. This number won't change, even if a display filter is used. Time The timestamp of the packet. The presentation format of this timestamp can be changed, see Section 6.12, Time display formats and time references. Source The address where this packet is coming from. Destination The address where this packet is going to. Protocol The protocol name in a short (perhaps abbreviated) version. Info Additional information about the packet content. There is a context menu (right mouse click) available, see details in Figure 6.4, Pop-up menu of the "Packet List" pane.

The colorized bullet on the left shows the highest expert info level found in the currently loaded capture file. Hovering the mouse over this icon will show a textual description of the expert info level, and clicking the icon will bring up the Expert Infos dialog box. For a detailed description of expert info, see Section 7.3, Expert Infos. The left side shows information about the capture file, its name, its size and the elapsed time while it was being captured. The middle part shows the current number of packets in the capture file. The following values are displayed: Packets: the number of captured packets Displayed: the number of packets currently being displayed Marked: the number of marked packets Dropped: the number of dropped packets (only displayed if Wireshark was unable to capture all packets) Ignored: the number of ignored packets (only displayed if packets are ignored) The right side shows the selected configuration profile. Clicking in this part of the statusbar will bring up a menu with all available configuration profiles, and selecting from this list will change the configuration profile.
Figure 3.22. The Statusbar with a configuration profile menu
For a detailed description of configuration profiles, see Section 10.6, Configuration Profiles.
Figure 3.23. The Statusbar with a selected protocol field
This is displayed if you have selected a protocol field from the "Packet Details" pane.
The value between the brackets (in this example arp.opcode) can be used as a display filter string, representing the selected protocol field.
Figure 3.24. The Statusbar with a display filter message
This is displayed if you are trying to use a display filter which may have unexpected results. For a detailed description, see Section 6.4.4, A common mistake.
Chapter 4. Capturing Live Network Data

4.1. Introduction

Capturing live network data is one of the major features of Wireshark. The Wireshark capture engine provides the following features: Capture from different kinds of network hardware (Ethernet, Token Ring, ATM,.). Stop the capture on different triggers like: amount of captured data, captured time, captured number of packets. Simultaneously show decoded packets while Wireshark keeps on capturing. Filter packets, reducing the amount of data to be captured, see Section 4.10, Filtering while capturing. Capturing into multiple files while doing a long term capture, and in addition the option to form a ringbuffer of these files, keeping only the last x files, useful for a "very long term" capture, see Section 4.8, Capture files and file modes. The capture engine still lacks the following features: Simultaneous capturing from multiple network interfaces (however, you can start multiple instances of Wireshark and merge capture files later). Stop capturing (or doing some other action), depending on the captured data.

Capture Filter

This field allows you to specify a capture filter. Capture filters are discussed in more details in Section 4.10, Filtering while capturing. It defaults to empty, or no filter. You can also click on the button labeled "Capture Filter", and Wireshark will bring up the Capture Filters dialog box and allow you to create and/or select a filter. Please see Section 6.6, Defining and saving filters

Compile BPF

This button allows you to compile the capture filter into BPF code and pop up a window showing you the resulting pseudo code. This can help in understanding the working of the capture filter you created.
4.5.2. Capture File(s) frame
An explanation about capture file usage can be found in Section 4.8, Capture files and file modes. File This field allows you to specify the file name that will be used for the capture file. This field is left blank by default. If the field is left blank, the capture data will be stored in a temporary file, see Section 4.8, Capture files and file modes for details. You can also click on the button to the right of this field to browse through the filesystem. Use multiple files Next file every n megabyte(s) Instead of using a single file, Wireshark will automatically switch to a new one, if a specific trigger condition is reached. Multiple files only: Switch to the next file after the given number of byte(s)/kilobyte(s)/megabyte(s)/gigabyte(s) have been captured. Multiple files only: Switch to the next file after the given number of second(s)/minutes(s)/hours(s)/days(s) have elapsed. Multiple files only: Form a ring buffer of the capture files, with the given number of files.
Next file every n minute(s) Ring buffer with n files
Stop capture after n file(s)
Multiple files only: Stop capturing after switching to the next file the given number of times.
4.5.3. Stop Capture. frame
. after n packet(s) Stop capturing after the given number of packets have been captured. Stop capturing after the given number of byte(s)/kilobyte(s)/ megabyte(s)/gigabyte(s) have been captured. This option is greyed out, if "Use multiple files" is selected. Stop capturing after the given number of second(s)/minutes(s)/ hours(s)/days(s) have elapsed.

. after n megabytes(s)

. after n minute(s)
4.5.4. Display Options frame
Update list of packets in real time This option allows you to specify that Wireshark should update the packet list pane in real time. If you do not specify this, Wireshark does not display any packets until you stop the capture. When you check this, Wireshark captures in a separate process and feeds the captures to the display process. This option allows you to specify that Wireshark should scroll the packet list pane as new packets come in, so you are always looking at the last packet. If you do not specify this, Wireshark simply adds new packets onto the end of the list, but does not scroll the packet list pane. This option is greyed out if "Update list of packets in real time" is disabled. If this option is checked, the capture info dialog described in Section 4.11, While a Capture is running. will be hidden.

The selection of capture formats may be reduced!
Some capture formats may not be available, depending on the packet types captured.
File formats can be converted!
You can convert capture files from one format to another by reading in a capture file and writing it out using a different format. 5. Click on the Save/Ok button to accept your selected file and save to it. If Wireshark has a problem saving the captured packets to the file you specified, it will display an error dialog box. After clicking OK on that error dialog box, you can try again. 6. Click on the Cancel button to go back to Wireshark and not save the captured packets.
5.3.2. Output File Formats
Wireshark can save the packet data in its "native" file format (libpcap) and in the file formats of some other protocol analyzers, so other tools can read the capture data.
File formats have different time stamp accuracies!
Saving from the currently used file format to a different format may reduce the time stamp accuracy; see the Section 7.4, Time Stamps for details. The following file formats can be saved by Wireshark (with the known file extensions): libpcap, tcpdump and various other tools using tcpdump's capture format (*.pcap,*.cap,*.dmp) Accellent 5Views (*.5vw) HP-UX's nettl (*.TRC0,*.TRC1) Microsoft Network Monitor - NetMon (*.cap) Network Associates Sniffer - DOS (*.cap,*.enc,*.trc,*fdc,*.syc) Network Associates Sniffer - Windows (*.cap) Network Instruments Observer version 9 (*.bfr) Novell LANalyzer (*.tr1) Sun snoop (*.snoop,*.cap) Visual Networks Visual UpTime traffic (*.*)
. new file formats are added from time to time If the above tools will be more helpful than Wireshark is a different question ;-)
Third party protocol analyzers may require specific file extensions!
Other protocol analyzers than Wireshark may require that the file has a certain file extension in order to read the files you generate with Wireshark, e.g.: ".cap" for Network Associates Sniffer - Windows
5.4. Merging capture files
Sometimes you need to merge several capture files into one. For example this can be useful, if you have captured simultaneously from multiple interfaces at once (e.g. using multiple instances of Wireshark). Merging capture files can be done in three ways: Use the menu item "Merge" from the "File" menu, to open the merge dialog, see Section 5.4.1, The "Merge with Capture File" dialog box. This menu item will be disabled, until you have loaded a capture file. Use drag-and-drop to drop multiple files on the main window. Wireshark will try to merge the packets in chronological order from the dropped files into a newly created temporary file. If you drop only a single file, it will simply replace a (maybe) existing one. Use the mergecap tool, which is a command line tool to merge capture files. This tool provides the most options to merge capture files, see Section D.8, mergecap: Merging multiple capture files into one.

The input parameters are as follows: Filename / Browse Enter the name of the text file to import. You can use Browse to browse for a file. Select the radix of the offsets given in the text file to import. This is usually hexadecimal, but decimal and octal are also supported. Tick this checkbox if there are timestamps associated with the frames in the text file to import you would like to use. Otherwise the current time is used for timestamping the frames. This is the format specifier used to parse the timestamps in the text file to import. It uses a simple syntax to describe the format of the timestamps, using %H for hours, %M for minutes, %S for seconds, etc. The straightforward HH:MM:SS format is covered by %T. For a full definition of the syntax look for strftime(3).

Offsets

Date/Time

Format

The import parameters are as follows: Encapsulation type Here you can select which type of frames you are importing. This all depends on from what type of medium the dump to import was taken. It lists all types that Wireshark understands, so as to pass the capture file contents to the right dissector. When Ethernet encapsulation is selected you have to option to prepend dummy headers to the frames to import. These headers can provide artificial Ethernet, IP, UDP or TCP or SCTP headers and SCTP data chunks. When selecting a type of dummy header the applicable entries are enabled, others are grayed out and default values are used. You may not be interested in the full frames from the text file, just the first part. Here you can define how much data from the start of the frame you want to import. If you leave this open the maximum is set to 64000 bytes.

Dummy header

Max. frame length
Once all input and import parameters are setup click OK to start the import.
If your current data wasn't saved before, you will be asked to save it first, before this dialog box is shown. When completed there will be a new capture file loaded with the frames imported from the text file.

5.6. File Sets

When using the "Multiple Files" option while doing a capture (see: Section 4.8, Capture files and file modes), the capture data is spread over several capture files, called a file set. As it can become tedious to work with a file set by hand, Wireshark provides some features to handle these file sets in a convenient way.
How does Wireshark detect the files of a file set? A filename in a file set uses the format Prefix_Number_DateTimeSuffix which might look like this: "test_00001_20060420183910.pcap". All files of a file set share the same prefix (e.g. "test") and suffix (e.g. ".pcap") and a varying middle part. To find the files of a file set, Wireshark scans the directory where the currently loaded file resides and checks for files matching the filename pattern (prefix and suffix) of the currently loaded file. This simple mechanism usually works well, but has its drawbacks. If several file sets were captured with the same prefix and suffix, Wireshark will detect them as a single file set. If files were renamed or spread over several directories the mechanism will fail to find all files of a set. The following features in the "File Set" submenu of the "File" menu are available to work with file sets in a convenient way: The List Files dialog box will list the files Wireshark has recognized as being part of the current file set. Next File closes the current and opens the next file in the file set. Previous File closes the current and opens the previous file in the file set.

7.7.4. IPX name resolution (network layer)
ipxnet name resolution (ipxnets file): XXX - add ipxnets name resolution explanation.
7.7.5. TCP/UDP port name resolution (transport layer)
Try to resolve a TCP/UDP port (e.g. 80) to something more "human readable". TCP/UDP port conversion (system service): Wireshark will ask the operating system to convert a TCP or UDP port to its well known name (e.g. 80 # http). XXX - mention the role of the /etc/services file (but don't forget the files and folders section)!

7.8. Checksums

Several network protocols use checksums to ensure data integrity.
Applying checksums as described here is also known as redundancy checking. What are checksums for? Checksums are used to ensure the integrity of data portions for data transmission or storage. A checksum is basically a calculated summary of such a data portion. Network data transmissions often produce errors, such as toggled, missing or duplicated bits. As a result, the data received might not be identical to the data transmitted, which is obviously a bad thing. Because of these transmission errors, network protocols very often use checksums to detect such errors. The transmitter will calculate a checksum of the data and transmits the data together with the checksum. The receiver will calculate the checksum of the received data with the same algorithm as the transmitter. If the received and calculated checksums don't match a transmission error has occurred. Some checksum algorithms are able to recover (simple) errors by calculating where the expected error must be and repairing it. If there are errors that cannot be recovered, the receiving side throws away the packet. Depending on the network protocol, this data loss is simply ignored or the sending side needs to detect this loss somehow and retransmits the required packet(s). Using a checksum drastically reduces the number of undetected transmission errors. However, the usual checksum algorithms cannot guarantee an error detection of 100%, so a very small number of transmission errors may remain undetected. There are several different kinds of checksum algorithms; an example of an often used checksum algorithm is CRC32. The checksum algorithm actually chosen for a specific network protocol will depend on the expected error rate of the network medium, the importance of error detection, the processor load to perform the calculation, the performance needed and many other things. Further information about checksums can be found at: http://en.wikipedia.org/wiki/Checksum.
7.8.1. Wireshark checksum validation
Wireshark will validate the checksums of several protocols, e.g.: IP, TCP, UDP,. It will do the same calculation as a "normal receiver" would do, and shows the checksum fields in the packet details with a comment, e.g.: [correct], [invalid, must be 0x12345678] or alike. Checksum validation can be switched off for various protocols in the Wireshark protocol preferences, e.g. to (very slightly) increase performance. If the checksum validation is enabled and it detected an invalid checksum, features like packet reassembling won't be processed. This is avoided as incorrect connection data could "confuse" the internal database.

persdata:path

This option forces Wireshark to exit when capturing is complete. It can be used with the -c option. It must be used in conjunction with the -i and -w options. This option provides the name of a capture file for Wireshark to read and display. This capture file can be in one of the formats Wireshark understands. This option specifies a display filter to be applied when reading packets from a capture file. The syntax of this filter is that of the display filters discussed in Section 6.3, Filtering packets while viewing. Packets not matching the filter are discarded. This option specifies the snapshot length to use when capturing packets. Wireshark will only capture <snaplen> bytes of data for each packet. This option specifies that Wireshark will display packets as it captures them. This is done by capturing in one process and displaying them in a separate process. This is the same as "Update list of packets in real time" in the Capture Options dialog box. This option sets the format of packet timestamps that are displayed in the packet list window. The format can be one of: r relative, which specifies timestamps are displayed relative to the first packet captured. a absolute, which specifies that actual times be displayed for all packets. ad absolute with date, which specifies that actual dates and times be displayed for all packets. d delta, which specifies that timestamps are relative to the previous packet. e epoch, which specifies that timestamps are seconds since epoch (Jan 1, 1970 00:00:00)

-r <infile>

-R <read (display) filter>
-s <capture snaplen>
-t <time stamp format>
The -v option requests Wireshark to print out its version information and exit. This option sets the name of the savefile to be used when saving a capture file.

-w <savefile>

-y <capture link type>
If a capture is started from the command line with -k, set the data link type to use while capturing packets. The values reported by -L are the values that can be used. Specify an option to be passed to a TShark module. The eXtension option is in the form extension_key:value, where extension_key can be: lua_script:lua_script_filename; Tells Wireshark to load the given script in addition to the default Lua scripts.

11.9.4.26. pinfo.desegment_len
Estimated number of additional bytes required for completing the PDU
11.9.4.27. pinfo.desegment_offset
Offset in the tvbuff at which the dissector will continue processing when next called
11.9.4.28. pinfo.private_data

Access to private data

11.10. Functions for writing dissectors

11.10.1. Dissector

A refererence to a dissector, used to call a dissector against a packet or a part of it.
11.10.1.1. Dissector.get(name)
Obtains a dissector reference by name

11.10.1.1.1. Arguments

name The name of the dissector

11.10.1.1.2. Returns

The Dissector reference
11.10.1.2. dissector:call(tvb, pinfo, tree)
Calls a dissector against a given packet (or part of it)

11.10.1.2.1. Arguments

tvb pinfo tree The buffer to dissect The packet info The tree on which to add the protocol items

11.10.2. DissectorTable

A table of subdissectors of a particular protocol (e.g. TCP subdissectors like http, smtp, sip are added to table "tcp.port"). Useful to add more dissectors to a table so that they appear in the Decode As. dialog.
11.10.2.1. DissectorTable.new(tablename, [uiname], [type], [base])
Creates a new DissectorTable for your dissector's use.

11.10.2.1.1. Arguments

tablename uiname (optional) type (optional) base (optional) The short name of the table. The name of the table in the User Interface (defaults to the name given). Either FT_UINT* or FT_STRING (defaults to FT_UINT32) Either BASE_NONE, BASE_DEC, BASE_HEX, BASE_OCT, BASE_DEC_HEX or BASE_HEX_DEC (defaults to BASE_DEC)

11.10.2.1.2. Returns

The newly created DissectorTable
11.10.2.2. DissectorTable.get(tablename)
Obtain a reference to an existing dissector table.

11.10.2.2.1. Arguments

tablename The short name of the table.

11.10.2.2.2. Returns

The DissectorTable

11.12.3.1. Tvb.new_real(bytearray, name)
Creates a new Tvb from a bytearray (it gets added to the current frame too)

11.12.3.1.1. Arguments

bytearray name The data source for this Tvb. The name to be given to the new data-source.

11.12.3.1.2. Returns

The created Tvb.
11.12.3.2. Tvb.tvb(range)
Creates a (sub)Tvb from using a TvbRange

11.12.3.2.1. Arguments

range The TvbRange from which to create the new Tvb.
11.12.3.3. tvb:__tostring()
Convert the bytes of a Tvb into a string, to be used for debugging purposes as '.' will be appended in case the string is too long.

11.12.3.3.1. Returns

The string.

11.12.3.4. tvb:len()

Obtain the length of a TVB

11.12.3.4.1. Returns

The length of the Tvb.

11.12.3.5. tvb:offset()

Returns the raw offset (from the beginning of the source Tvb) of a sub Tvb.

11.12.3.5.1. Returns

The raw offset of the Tvb.

11.12.3.6. tvb:__call()

Equivalent to tvb:range(.)
11.12.3.7. wslua:__concat()
Concatenate two objects to a string

11.12.4. TvbRange

A TvbRange represents an usable range of a Tvb and is used to extract data from the Tvb that generated it TvbRanges are created by calling a tvb (e.g. tvb(offset,length)). If the TvbRange span is outside the Tvb's range the creation will cause a runtime error.
11.12.4.1. tvb:range([offset], [length])
Creates a tvbr from this Tvb. This is used also as the Tvb:__call() metamethod.

11.12.4.1.1. Arguments

offset (optional) length (optional) The offset (in octets) from the begining of the Tvb. Defaults to 0. The length (in octets) of the range. Defaults to until the end of the Tvb.

11.12.4.1.2. Returns

The TvbRange
11.12.4.2. tvbrange:uint()
Get a Big Endian (network order) unsigned integer from a TvbRange. The range must be 1, 2, 3 or 4 octets long.

11.12.4.2.1. Returns

The unsigned integer value
11.12.4.3. tvbrange:le_uint()
Get a Little Endian unsigned integer from a TvbRange. The range must be 1, 2, 3 or 4 octets long.

11.12.4.3.1. Returns

11.12.4.4. tvbrange:uint64()
Get a Big Endian (network order) unsigned 64 bit integer from a TvbRange. The range must be 1-8 octets long.
11.12.4.5. tvbrange:le_uint64()
Get a Little Endian unsigned 64 bit integer from a TvbRange. The range must be 1-8 octets long.
11.12.4.6. tvbrange:int()
Get a Big Endian (network order) signed integer from a TvbRange. The range must be 1, 2 or 4 octets long.

11.12.4.6.1. Returns

The signed integer value
11.12.4.7. tvbrange:le_int()
Get a Little Endian signed integer from a TvbRange. The range must be 1, 2 or 4 octets long.

IPv4 and IPv6 /etc/hosts, %WIRESHARK%\hosts, %APPDATA% name resolution. $HOME/.wireshark/\Wireshark\hosts hosts Network services. /etc/services, %WIRESHARK%\services, $HOME/.wireshark/%APPDATA%\Wireshark\services services IPv4 subnet name /etc/subnets, %WIRESHARK%\subnets, resolution. $HOME/.wireshark/%APPDATA%\Wireshark\subnets subnets

services

subnets

File/Folder ipxnets

Description IPX resolution.

Unix/Linux folders

Windows folders
name /etc/ipxnets, %WIRESHARK%\ipxnets, %APPDATA $HOME/.wireshark/%\Wireshark\ipxnets ipxnets

plugins

Plugin directories. /usr/share/ %WIRESHARK%\plugins\<version>, wireshark/ %APPDATA%\Wireshark\plugins plugins, /usr/local/ share/wireshark/ plugins, $HOME/.wireshark/ plugins Temporary files. Environment: TMPDIR Environment: TMPDIR or TEMP
%APPDATA% points to the personal configuration folder, e.g.: C:\Documents and Settings\<username>\Application Data (details can be found at: Section A.3.1, Windows profiles), %WIRESHARK% points to the Wireshark program folder, e.g.: C:\Program Files \Wireshark
The /etc folder is the global Wireshark configuration folder. The folder actually used on your system may vary, maybe something like: /usr/local/etc. $HOME is usually something like: /home/<username> preferences/wireshark.conf This file contains your Wireshark preferences, including defaults for capturing and displaying packets. It is a simple text file containing statements of the form:

variable: value

The settings from this file are read in at program start and written to disk when you press the Save button in the "Preferences" dialog box. recent This file contains various GUI related settings like the main window position and size, the recent files list and such. It is a simple text file containing statements of the form:
It is read at program start and written at program exit. cfilters This file contains all the capture filters that you have defined and saved. It consists of one or more lines, where each line has the following format:
"<filter name>" <filter string>
The settings from this file are read in at program start and written to disk when you press the Save button in the "Capture Filters" dialog box. dfilters This file contains all the display filters that you have defined and saved. It consists of one or more lines, where each line has the following format:

Output format: -L generate long report (default) -T generate table report Table report options: -R generate header record (default) -r do not generate header record -B separate infos with TAB character (default) -m separate infos with comma (,) character -b separate infos with SPACE character -N do not quote infos (default) -q quote infos with single quotes (') -Q quote infos with double quotes (") Miscellaneous: -h display this help and exit -C cancel processing if file open fails (default is to continue) -A generate all infos (default) Options are processed from left to right order with later options superceeding or adding to earlier options. If no options are given the default is to display all infos in long report output format.
D.6. rawshark: Dump and analyze network traffic.
Rawshark reads a stream of packets from a file or pipe, and prints a line describing its output, followed by a set of matching fields for each packet on stdout.
Example D.4. Help information available from rawshark
Rawshark 1.6.0 (SVN Rev 37205 from /trunk-1.6) Dump and analyze network traffic. See http://www.wireshark.org for more information. Copyright 1998-2011 Gerald Combs <gerald@wireshark.org> and contributors. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Usage: rawshark [options]. Input file: -r <infile>
set the pipe or file name to read from
Processing: -d <encap:dlt>|<proto:protoname> packet encapsulation or protocol -F <field> field to display -n disable all name resolution (def: all enabled) -N <name resolve flags> enable specific name resolution(s): "mntC" -p use the system's packet header format (which may have 64-bit timestamps) -R <read filter> packet filter in Wireshark display filter syntax -s skip PCAP header on input Output: -l flush output after each packet -S format string for fields (%D - name, %S - stringval, %N numval) -t ad|a|r|d|dd|e output format of time stamps (def: r: rel. to first) Miscellaneous: -h -o <name>:<value>. -v
display this help and exit override preference setting display version info and exit
D.7. editcap: Edit capture files
Included with Wireshark is a small utility called editcap, which is a command-line utility for working with capture files. Its main function is to remove packets from capture files, but it can also be used to convert capture files from one format to another, as well as to print information about capture files.

10.2.2. GTK Version 2.x... 10.2.3. Compatibility GTK versions... 10.2.4. GTK resources on the web... 10.3. GUI Reference documents... 10.4. Adding/Extending Dialogs... 10.5. Widget naming.... 10.6. Common GTK programming pitfalls... 10.6.1. Usage of gtk_widget_show() / gtk_widget_show_all().. A. This Document's License (GPL)...

Preface

1. Foreword
This book tries to give you a guide to start your own experiments into the wonderful world of Wireshark development. Developers who are new to Wireshark often have a hard time getting their development environment up and running. This is especially true for Win32 developers, as a lot of the tools and methods used when building Wireshark are much more common in the UNIX world than on Win32. The first part of this book will describe how to set up the environment needed to develop Wireshark. The second part of this book will describe how to change the Wireshark source code. We hope that you find this book useful, and look forward to your comments.
2. Who should read this document?
The intended audience of this book is anyone going into the development of Wireshark. This book is not intended to explain the usage of Wireshark in general. Please refer the Wireshark User's Guide about Wireshark usage. By reading this book, you will learn how to develop Wireshark. It will hopefully guide you around some common problems that frequently appear for new (and sometimes even advanced) developers of Wireshark.

3. Acknowledgements

The authors would like to thank the whole Wireshark team for their assistance. In particular, the authors would like to thank: Gerald Combs, for initiating the Wireshark project. Guy Harris, for many helpful hints and his effort in maintaining the various contributions on the mailing lists. The authors would also like to thank the following people for their helpful feedback on this document: XXX - Please give feedback :-) And of course a big thank you to the many, many contributors of the Wireshark development community!

#MSVC_VARIANT=MSVC2008EE

and remove the comment character (#) from the beginning of the line. Then, find the line

MSVC_VARIANT=MSVC2008

Quick Setup and comment it out, by prefixing a hash (#). 1
Compiler dependent: This step depends on the compiler you are using. For compilers other than Visual C++ 2008, see the table at Section 4.4, Microsoft compiler toolchain (Win32 native).
International Windows might use different values here, e.g. a German version uses C:\Programme take this also in account where C:\Program Files appears elsewhere.

2.2.6. Prepare cmd.exe

Prepare cmd.exe - set environment and current dir. 1. start cmd.exe 2. call C:\Program Files\Microsoft Visual Studio 9.0\VC\bin\vcvars32.bat to set environment variables of Visual C++ 2008 Express Edition. 1,2 3. cd C:\wireshark to jump into the source directory
Compiler dependent: This step depends on the compiler variant used, for other variants than the recommended Visual C++ 2008 Express Edition see the table at Section 4.4, Microsoft compiler toolchain (Win32 native)!
International Windows might use different values here, e.g. a German version uses C:\Programme take this also in account where C:\Program Files appears elsewhere. Note: You need to repeat steps 1 - 4 each time you open a new cmd.exe!
2.2.7. Verify installed tools
After you've installed the Wireshark sources (see Section 3.3, Obtain the Wireshark sources), you can check the correct installation of all tools by using the verify_tools target of the Makefile.nmake from the source package.
You will need the Wireshark sources and some tools (nmake, bash) installed, before this verification is able to work. Enter at the command line (cmd.exe, not Cygwin's bash!): > nmake -f Makefile.nmake verify_tools This will check for the various tools needed to build Wireshark:
Checking for required applications: cl: /cygdrive/c/Programme/Microsoft Visual Studio 8/VC/BIN/cl link: /cygdrive/c/Programme/Microsoft Visual Studio 8/VC/BIN/link nmake: /cygdrive/c/Programme/Microsoft Visual Studio 8/VC/BIN/nmake bash: /usr/bin/bash bison: /usr/bin/bison flex: /usr/bin/flex env: /usr/bin/env grep: /usr/bin/grep /usr/bin/find: /usr/bin/find perl: /usr/bin/perl env: /usr/bin/env C:/python27/python.exe: /cygdrive/c/python27/python.exe
sed: /usr/bin/sed unzip: /usr/bin/unzip wget: /usr/bin/wget
If you have problems with all the first three items (cl, link, nmake), check if you called vcvars32/ SetEnv as mentioned in Section 2.2.6, Prepare cmd.exe (which will "fix" your PATH settings). However, the exact text will be slightly different depending on the MSVC version used. Unfortunately, the link command is defined both in Cygwin and in MSVC each with completely different functionality; you'll need the MSVC link. If your link command looks something like: /usr/bin/link, the link command of Cygwin takes precedence over the MSVC one. To fix this, you can change your PATH environment setting or simply rename the link.exe in Cygwin. If you rename it, make sure to remember that a Cygwin update may provide a new version of it.

2.2.8. Install Libraries

1. If you've closed cmd.exe in the meantime, prepare cmd.exe again. 2. nmake -f Makefile.nmake setup downloads libraries using wget and installs them - this may take a while. 3. If the download fails you may be behind a restrictive firewall, see the proxy comment in Section 4.15, Win32: GNU wget (optional).

2.2.9. Distclean Sources

The released Wireshark sources contain files that are prepared for a UNIX build (e.g. config.h). You must distclean your sources before building the first time! 1. If you've closed cmd.exe in the meantime, prepare cmd.exe again 2. nmake -f Makefile.nmake distclean to cleanup the Wireshark sources

2.2.10. Build Wireshark

Now it's time to build Wireshark. 1. If you've closed cmd.exe in the meantime, prepare cmd.exe again 2. nmake -f Makefile.nmake all to build Wireshark 3. wait for Wireshark to compile - this may take a while! 4. run C:\wireshark\wireshark-gtk2\wireshark.exe and check if it starts 5. check Help/About if it shows your "private" program version, e.g.: Version 1.4.x-myprotocol123 - you might run a release version previously installed! Tip: If compilation fails for suspicious reasons after you changed some source files try to "distclean" the sources and make "all" again
2.2.11. Debug Environment Setup (XXX)
XXX - debug needs to be written, e.g. an idea is the create a simple MSVC workspace/project(s) to ease Visual Studio debugging
2.2.12. Optional: Create User's and Developer's Guide
Detailed information to build these guides can be found in the file docbook/README.txt in the Wireshark sources.
2.2.13. Optional: Create a Wireshark Installer
Note: You should have successfully built Wireshark before doing the following! If you want to build your own wireshark-win32-1.4.x-myprotocol123.exe, you'll need NSIS. 1. NSIS: Download and install NSIS You may check the MAKENSIS setting in the file config.nmake of the Wireshark sources. 2. vcredist_x86.exe : Download the C-Runtime redistributable for Visual C++ 2008 Express Edition SP1 (vcredist_x86.exe) and copy it into C:\wireshark-win32-libs 1 3. If you've closed cmd.exe in the meantime, prepare cmd.exe again 4. nmake -f Makefile.nmake packaging build Wireshark installer 5. run C:\wireshark\packaging\nsis\wireshark-win32-1.4.x-myprotocol123.exe and test it - it's a good idea to test also on a different machine than the developer machine.

Compiler dependent: This step depends on the compiler variant used; for other variants than the recommended Visual C++ 2008 Express Edition SP1 see the table at Section 4.4, Microsoft compiler toolchain (Win32 native)!
Chapter 3. Work with the Wireshark sources

3.1. Introduction

This chapter will explain how to work with the Wireshark source code. It will show you how to: get the source compile the source submit changes . However, this chapter will not explain the source file contents in detail, such as where to find a specific functionality. This is done in Section 7.1, Source overview.
3.2. The Wireshark Subversion repository
Subversion is used to keep track of the changes made to the Wireshark source code. The Wireshark source code is stored inside Wireshark project's Subversion repository located at a server at the wireshark.org domain. To quote the Subversion book about "What is Subversion?": Subversion is a free/open-source version control system. That is, Subversion manages files and directories over time. A tree of files is placed into a central repository. The repository is much like an ordinary file server, except that it remembers every change ever made to your files and directories. This allows you to recover older versions of your data, or examine the history of how your data changed. In this regard, many people think of a version control system as a sort of "time machine".
Tip: Subversion and SVN is the same!
Subversion is often abbreviated as SVN, as the command-line tools are abbreviated that way. You will find both terms with the same meaning in this book, in mailing list discussions and elsewhere. Using Wireshark's Subversion repository you can: keep your private sources up to date with very little effort get a mail notification if someone changes the latest sources get the source files from any previous release (or any other point in time) have a quick look at the sources using a web interface see which person changed a specific piece of code . and a lot more things related to the history of the Wireshark source code development

3.3.1. Anonymous Subversion access
Recommended for development purposes. Age: a few minutes.
You can use a Subversion client to download the source code from Wireshark's anonymous Subversion repository. The URL for the repository trunk is: http://anonsvn.wireshark.org/wireshark/trunk/. See Section 4.11, Subversion (SVN) client (optional) on how to install a Subversion client. For example, to check out using the command-line Subversion client, you would type: $ svn checkout http://anonsvn.wireshark.org/wireshark/trunk wireshark The checkout has to be only done once. This will copy all the sources of the latest version (including directories) from the server to your machine. This will take some time, depending on the speed of your internet connection.
3.3.2. Anonymous Subversion web interface
Recommended for informational purposes only, as only individual files can be downloaded. Age: a few minutes (same as anonymous Subversion access). The entire source tree of the Subversion repository is available via a web interface at: http:// anonsvn.wireshark.org/viewvc/viewvc.cgi/. You can view each revision of a particular file, as well as diffs between different revisions. You can also download individual files but not entire directories.
3.3.3. Buildbot Snapshots
Recommended for development purposes, if direct Subversion access isn't possible (e.g. because of a restrictive firewall). Age: some number of minutes (a bit older than the anonymous Subversion access). The buildbot server will automatically start to generate a snapshot of Wireshark's source tree after a source code change is committed. These snapshots can be found at: http://www.wireshark.org/download/ automated/src/. If anonymous Subversion access isn't possible, e.g. if the connection to the server isn't possible because of a corporate firewall, the sources can be obtained by downloading the buildbot snapshots. However, if you are going to maintain your sources in parallel to the "official" sources for some time, it's recommended to use the anonymous Subversion access if possible (believe it, it will save you a lot of time).

3.3.4. Released sources

Recommended for productive purposes. Age: from days to weeks. The officially released source files can be found at: http://www.wireshark.org/download/. You should use these sources if you want to build Wireshark on your platform for productive use. The differences between the released sources and the sources stored at the Subversion repository will keep on growing until the next release is done (at the release time, the released and latest Subversion repository versions are then identical again :-).

You will probably have to modify the MAKENSIS setting in the config.nmake file to specify where the NSIS binaries are installed. In the wireshark directory, type: > nmake -f makefile.nmake packaging to build the installer.
Please be patient while the compression is done, it will take some time (a few minutes!) even on fast machines. If everything went well, you will now find something like: wireshark-setup-1.4.exe in the packaging/nsis directory.
Chapter 4. Tool Reference

4.1. Introduction

This chapter will provide you with information about the various tools needed for Wireshark development. None of the tools mentioned in this chapter are needed to run Wireshark; they are only needed to build it. Most of these tools have their roots on UNIX like platforms, but Win32 ports are also available. Therefore the tools are available in different "flavours": UNIX (or Win32 Cygwin): the tools should be commonly available on the supported UNIX platforms, and for Win32 platforms by using the Cygwin UNIX emulation Win32 native: some tools are available as native Win32 tools, no special emulation is required
Unless you know exactly what you are doing, you should strictly follow the recommendations given in Chapter 2, Quick Setup! The following sections give a very brief description of what a particular tool is doing, how it is used in the Wireshark project and how it can be installed and tested. Don't expect a lot of documentation regarding these tools in this document. If you need further documentation of a specific tool, you should find lot's of useful information on the web, as these tools are commonly used. You can also try to get help for the UNIX based tools with toolname --help or read the manpage man toolname. You will find explanations of the tool usage for some of the specific development tasks in Chapter 3, Work with the Wireshark sources.

4.2. Win32: Cygwin

Cygwin provides a lot of UNIX based tools on the Win32 platform. It uses a UNIX emulation layer which might be a bit slower compared to the native Win32 tools, but at an acceptable level. The installation and update is pretty easy and done through a single (web based) setup.exe. The native Win32 tools will typically be a bit faster, but more complicated to install, as you would have to download the tools from different webpages, and install them in different ways, tweaking the PATH and alike.

diff (GNU diffutils) 2.8.7 Written by Paul Eggert, Mike Haertel, David Hayes, Richard Stallman, and Len Tower. Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
4.13.2. Win32 native: diff
A native Win32 diff package can be obtained from http://gnuwin32.sourceforge.net/. The installation should be straightforward. The Subversion client TortoiseSVN has a built-in diff feature, see Section 4.12.2, Win32 native: TortoiseSVN. It is currently unknown if this tool can be used to create diff files in the required format, so other persons can use them.

4.14. patch (optional)

The patch utility is used to merge a diff file into your own source tree. This tool is only needed, if you want to apply a patch (diff file) from someone else (probably from the developer mailing list) to try out in your own private source tree.
Unless you are in the rare case needing to apply a patch to your private source tree, you won't need the patch tool installed. You will find more instructions in Section 3.10, Apply a patch from someone else on how to use the patch tool.
4.14.1. UNIX or Win32 Cygwin: patch
Patch is available for most of the UNIX-like platforms and as the patch package from the Cygwin setup. If GNU patch isn't already installed or available as a package for your platform, you can get it at: http:// www.gnu.org/software/patch/patch.html. After correct installation, typing at the bash command line prompt: $ patch --version should result in something like:
patch 2.5.8 Copyright (C) 1988 Larry Wall Copyright (C) 2002 Free Software Foundation, Inc. This program comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of this program under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING. written by Larry Wall and Paul Eggert
4.14.2. Win32 native: patch
A native Win32 patch package can be obtained from http://gnuwin32.sourceforge.net/. The installation should be straightforward.
The Subversion client TortoiseSVN has a built-in patch feature, see Section 4.12.2, Win32 native: TortoiseSVN. The last time tested (Version 1.1.0), this feature failed to apply patches known to be ok.

The "Gcrypt Library" is Low-level encryption library and provides support for many ciphers, such as DES, 3DES, AES, Blowfish, and others.

5.12.1. Unix

If this library isn't already installed or available as a package for your platform, you can get it at: http:// directory.fsf.org/security/libgcrypt.html.

5.12.2. Win32 MSVC

Part of our homemade GnuTLS package.
5.13. Kerberos (optional)
The Kerberos library is used to dissect Kerberos, sealed DCERPC and secureLDAP protocols.

5.13.1. Unix

If this library isn't already installed or available as a package for your platform, you can get it at: http:// web.mit.edu/Kerberos/dist/. XXX - Is it supported on *NIX at all?

5.13.2. Win32 MSVC

You can get the latest version of KfW "Kerberos for Windows" at: http://web.mit.edu/Kerberos/dist/

5.14. LUA (optional)

The LUA library is used to add scripting support to Wireshark.

5.14.1. Unix

If this library isn't already installed or available as a package for your platform, you can get it at: http:// www.lua.org/download.html.

5.14.2. Win32 MSVC

You can get the latest version at: http://luaforge.net/frs/?group_id=110
5.15. PortAudio (optional)
The PortAudio library enables audio output for RTP streams.

5.15.1. Unix

If this library isn't already installed or available as a package for your platform, you can get it at: http:// www.portaudio.com/download.html.

5.15.2. Win32 MSVC

You can get the latest version at: http://www.portaudio.com/download.html

5.16. GeoIP (optional)

MaxMind Inc. publishes a GeoIP database for use in open source software. It can be used to map IP addresses to geographical locations.

5.16.1. Unix

If this library isn't already installed or available as a package for your platform, you can get it at: http:// www.maxmind.com/app/c.

guint8 flags = tvb_get_guint8(tvb, offset); offset ++; if (flags & FLAG_COMPRESSED) { /* the remainder of the packet is compressed */ guint16 orig_size = tvb_get_ntohs(tvb, offset); guchar *decompressed_buffer = (guchar*)g_malloc(orig_size); offset += 2; decompress_packet(tvb_get_ptr(tvb, offset, -1), tvb_length_remaining(tvb, offset), decompressed_buffer, orig_size); /* Now re-setup the tvb buffer to have the new data */ next_tvb = tvb_new_real_data(decompressed_buffer, orig_size, orig_size); tvb_set_child_real_data_tvbuff(tvb, next_tvb); add_new_data_source(pinfo, next_tvb, "Decompressed Data"); } else { next_tvb = tvb_new_subset(tvb, offset, -1, -1); } offset = 0; /* process next_tvb from here on */
The first steps here are to recognise the compression. In this case a flag byte alerts us to the fact the remainder of the packet is compressed. Next we retrieve the original size of the packet, which in this case is conveniently within the protocol. If it's not, it may be part of the compression routine to work it out for you, in which case the logic would be different. So armed with the size, a buffer is allocated to receive the uncompressed data using g_malloc, and the packet is decompressed into it. The tvb_get_ptr() function is useful to get a pointer to the raw data of the packet from the offset onwards. In this case the decompression routine also needs to know the length, which is given by the tvb_length_remaining() function. Next we build a new tvb buffer from this data, using the tvb_new_real_data() call. This data is a child of our original data, so we acknowledge that in the next call to tvb_set_child_real_data_tvbuff. Finally we add this data as a new data source, so that the detailed display can show the decompressed bytes as well as the original. One procedural step is to add a handler to free the data when it's no longer needed. In this case as g_malloc() was used to allocate the memory, g_free() is the appropriate function. After this has been set up the remainder of the dissector can dissect the buffer next_tvb, as it's a new buffer the offset needs to be 0 as we start again from the beginning of this buffer. To make the rest of the dissector work regardless of whether compression was involved or not, in the case that compression was not signaled, we use the tvb_new_subset() to deliver us a new buffer based on the old one but starting at the current offset, and extending to the end. This makes dissecting the packet from this point on exactly the same regardless of compression.
9.4. How to reassemble split packets
Some protocols have times when they have to split a large packet across multiple other packets. In this case the dissection can't be carried out correctly until you have all the data. The first packet doesn't have enough data, and the subsequent packets don't have the expect format. To dissect these packets you need to wait until all the parts have arrived and then start the dissection.

These hf variables are used internally within the reassembly routines to make useful links, and to add data to the dissection. It produces links from one packet to another - such as a partial packet having a link to the fully reassembled packet. Likewise there are back pointers to the individual packets from the reassembled one. The other variables are used for flagging up errors.
9.4.2. How to reassemble split TCP Packets
A dissector gets a tvbuff_t pointer which holds the payload of a TCP packet. This payload contains the header and data of your application layer protocol. When dissecting an application layer protocol you cannot assume that each TCP packet contains exactly one application layer message. One application layer message can be split into several TCP packets. You also cannot assume that a TCP packet contains only one application layer message and that the message header is at the start of your TCP payload. More than one messages can be transmitted in one TCP packet, so that a message can start at an arbitrary position. This sounds complicated, but there is a simple solution. tcp_dissect_pdus() does all this tcp packet reassembling for you. This function is implemented in epan/dissectors/packet-tcp.h.
Example 9.18. Reassembling TCP fragments
#ifdef HAVE_CONFIG_H # include "config.h" #endif #include <epan/packet.h> #include <epan/prefs.h> #include "packet-tcp.h". #define FRAME_HEADER_LEN 8 /* The main dissecting routine */ static void dissect_foo(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree) { tcp_dissect_pdus(tvb, pinfo, tree, TRUE, FRAME_HEADER_LEN, get_foo_message_len, dissect_foo_message); } /* This method dissects fully reassembled messages */ static void dissect_foo_message(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree) { /* TODO: implement your dissecting code */ } /* determine PDU length of protocol foo */ static guint get_foo_message_len(packet_info *pinfo, tvbuff_t *tvb, int offset) { /* TODO: change this to your needs */ return (guint)tvb_get_ntohl(tvb, offset+4); /* e.g. length is at offset 4 */ }.
As you can see this is really simple. Just call tcp_dissect_pdus() in your main dissection routine and move you message parsing code into another function. This function gets called whenever a message has been reassembled.

9.6. How to produce protocol stats
Given that you have a tap interface for the protocol, you can use this to produce some interesting statistics (well presumably interesting!) from protocol traces. This can be done in a separate plugin, or in the same plugin that is doing the dissection. The latter scheme is better, as the tap and stats module typically rely on sharing protocol specific data, which might get out of step between two different plugins. Here is a mechanism to produce statistics from the above TAP interface.
Example 9.21. Initialising a stats interface
/* register all http trees */ static void register_foo_stat_trees(void) { stats_tree_register("foo", "foo", "Foo/Packet Types", foo_stats_tree_packet, foo_stats_tree_init, NULL); } G_MODULE_EXPORT const gchar version[] = "0.0"; G_MODULE_EXPORT void plugin_register_tap_listener(void) { register_foo_stat_trees(); } #endif
Working from the bottom up, first plugin_register_tap_listener(). register_foo_stat_trees().
the plugin interface entry point is This simply calls the initialisation

defined, function

This in turn calls the stats_tree_register() function, which takes three strings, and three functions. 1. This is the tap name that is registered. 2. An abbreviation of the stats name. 3. The name of the stats module. A '/' character can be used to make sub menus.
4. The function that will called to generate the stats. 5. A function that can be called to initialise the stats data. 6. A function that will be called to clean up the stats data. In this case we only need the first two functions, as there is nothing specific to clean up.
Example 9.22. Initialising a stats session
static static static static const guint8* st_str_packets = "Total Packets"; const guint8* st_str_packet_types = "FOO Packet Types"; int st_node_packets = -1; int st_node_packet_types = -1;
static void foo_stats_tree_init(stats_tree* st) { st_node_packets = stats_tree_create_node(st, st_str_packets, 0, TRUE); st_node_packet_types = stats_tree_create_pivot(st, st_str_packet_types, st_node_packets); }
In this case we create a new tree node, to handle the total packets, and as a child of that we create a pivot table to handle the stats about different packet types.

XXX: include Wireshark GTK2 screenshot
10.2.3. Compatibility GTK versions
The GTK library itself defines some values which makes it easy to distinguish between the versions, e.g.: GTK_MAJOR_VERSION and GTK_MINOR_VERSION will be set to the GTK version at compile time inside the gtkversion.h header.
10.2.4. GTK resources on the web
You can find several resources about GTK. First of all, have a look at: http://www.gtk.org as this will be the first place to look at. If you want to develop GTK related things for Wireshark, the most important place might be the GTK API documentation at: http://library.gnome.org/devel/gtk/stable/. Several mailing lists are available about GTK development, see http://mail.gnome.org/mailman/listinfo, the gtk-app-devel-list may be your friend. As it's often done wrong: You should post a mail to *help* the developers there instead of only complaining. Posting such a thing like "I don't like your dialog, it looks ugly" won't be of much help. You might think about what you dislike and describe why you dislike it and provide a suggestion for a better way.
10.3. GUI Reference documents
Although the GUI development of Wireshark is platform independent, the Wireshark development team tries to follow the GNOME Human Interface Guidelines (HIG) where appropriate. This is the case, because both GNOME and Wireshark are based on the GTK+ toolkit and the GNOME HIG is excellently written and easy to understand. For further reference, see the following documents: GNOME Human Interface Guidelines at: http://library.gnome.org/devel/hig-book/stable/ KDE user interface related documents at: http://developer.kde.org/documentation/standards/kde/style/ basics/index.html Win32 styleguides available at: http://msdn.microsoft.com/en-us/library/aa511258.aspx
10.4. Adding/Extending Dialogs
This is usually the main area for contributing new user interface features. XXX: add the various functions from gtk/dlg_utils.h

10.5. Widget naming

It seems to be common sense to name the widgets with some descriptive trailing characters, like: xy_lb = gtk_label_new(); xy_cb = gtk_checkbox_new();
XXX: add more examples However, this schema isn't used at all places inside the code.
10.6. Common GTK programming pitfalls

This Document's License (GPL)
program will individually obtain patent licenses, in effect making the program proprietary. To prevent this, we have made it clear that any patent must be licensed for everyone's free use or not licensed at all. The precise terms and conditions for copying, distribution and modification follow. GNU GENERAL PUBLIC LICENSE TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION 0. This License applies to any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Public License. The "Program", below, refers to any such program or work, and a "work based on the Program" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. (Hereinafter, translation is included without limitation in the term "modification".) Each licensee is addressed as "you". Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does. 1. You may copy and distribute verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and give any other recipients of the Program a copy of this License along with the Program. You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee. 2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change. b) You must cause any work that whole or in part contains or is part thereof, to be licensed as parties under the terms of this you distribute or publish, that in derived from the Program or any a whole at no charge to all third License.