[#ChapterSources]

== Work with the Wireshark sources

[#ChSrcIntro]

=== Introduction

This chapter will explain how to work with the Wireshark source code.
It will show you how to:

* Get the source

* Compile it on your machine

* Submit changes for inclusion in the official release

This chapter will not explain the source file contents in detail,
such as where to find specific functionality. This is done in
<<ChCodeOverview>>.

[#ChSrcGitRepository]

=== The Wireshark Git repository

https://git-scm.com/[Git] is used to keep track of the changes made to the Wireshark source code.
The official repository is hosted at {wireshark-gitlab-project-url}[GitLab], and incoming changes are evaluated and reviewed there.
For more information on GitLab see https://docs.gitlab.com/ee/[their documentation].

.Why Git?

Git is a fast, flexible way of managing source code.
It allows large scale distributed development and ensures data integrity.

.Why GitLab?

GitLab makes it easy to contribute.
You can make changes locally and push them to your own work area at gitlab.com, or if your change is minor you can make changes entirely within your web browser.

.Historical trivia: GitLab is the *fourth* iteration of our source code repository and code review system.
// Five if you include "sending patches to Gerald."

Wireshark originally used https://www.nongnu.org/cvs/[Concurrent Versions System] (CVS) and migrated to https://subversion.apache.org/[Subversion] in July 2004.
We migrated from Subversion to Git and https://www.gerritcodereview.com/[Gerrit] in January 2014, and from Gerrit to GitLab in August 2020.

Using Wireshark’s GitLab project you can:

* Keep your private sources up to date with very little effort.
* Receive notifications about code reviews and issues.
* Get the source files from any previous release (or any other point in time).
* Browse and search the source code using a web interface.
* See which person changed a specific piece of code.

[#ChSrcGitNamingConventions]

==== Git Naming Conventions

Like most revision control systems, Git uses
https://en.wikipedia.org/wiki/Branching_%28revision_control%29[branching]
to manage different copies of the source code and allow parallel development.
Wireshark releases use the following branch naming conventions:

.master.
Main feature development and odd-numbered development releases.

.release-x.y.
Stable release maintenance. For example, release-4.4 is used to manage the 4.4.x official releases.

Tags for major Wireshark releases and release candidates consist of a “v” followed by a version number such as “v4.4.1” or “v4.4.3rc0”.
Major releases additionally have a tag prefixed with “wireshark-” followed by a version number, such as “wireshark-4.4.0”.

Tags for major Stratoshark releases and release candidates consist of an “ssv” followed by a version number such as “ssv1.2.3” or “ssv1.3.4rc0”.

Tags created after August 1, 2024 are signed using SSH. This includes the tags for versions 4.4.0rc1, 4.4.0, 4.2.7, and 4.0.17. If you wish to verify these tags, you must have
https://git-scm.com/docs/git-config#Documentation/git-config.txt-gpgsshallowedSignersFile[gpg.ssh.allowedSignersFile]
configured and have the following entry in your “allowed signers” file:

    gerald@wireshark.org namespaces="git" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIBHe1qOxwBietT54lZ3qawTc8B9unWP+T3JVR9l2rQaP

Tags were signed using GPG prior to August 2024.

[#ChSrcGitWeb]
=== Browsing And Searching The Source Code

If you need a quick look at the Wireshark source code you can browse the repository files in GitLab at

{wireshark-code-browse-url}

You can view commit logs, branches, and tags, find files and search the repository contents.
You can also download individual files.

[#ChSrcObtain]
=== Obtaining The Wireshark Sources

There are two primary ways to obtain Wireshark’s source code: Git and compressed .tar archives.
Each is described in more detail below.
We recommend using Git for day to day development, particularly if you wish to contribute changes back to the project.
The age mentioned in the following sections indicates the age of the most recent change in that set of the sources.


[#ChSrcGit]
==== Git Over SSH Or HTTPS

This method is strongly recommended for day to day development.

You can use a Git client to download the source code from Wireshark’s code review system.
Anyone can clone from the anonymous HTTP git URL:

{wireshark-git-anonhttp-url}

If you have a GitLab account you can also clone using SSH:

{wireshark-git-ssh-url}

If wish to make changes to Wireshark you must create a GitLab account, create a fork of the official Wireshark repository, update your fork, and create a merge request.
See <<ChSrcContribute>> for details.

The following example shows how to get up and running on the command line.
See <<ChToolsGit>> for information on installing and configuring graphical Git clients.

. Now on to the command line.
First, make sure `git` works:
+
--
[source,sh]
----
$ git --version
----
--

. If this is your first time using Git, make sure your username and email address are configured.
This is particularly important if you  plan on uploading changes:
+
--
[source,sh]
----
$ git config --global user.name "Henry Perry"
$ git config --global user.email henry.perry@example.com
----
--

. Next, clone the Wireshark repository:
+
--
[source,sh]
----
# If you have a GitLab account, you can use the SSH URL:
$ git clone -o upstream git@gitlab.com:wireshark/wireshark.git
# If you don't you can use the HTTPS URL:
$ git clone -o upstream https://gitlab.com/wireshark/wireshark.git
# You can speed up cloning in either case by adding --shallow-since=1year or --depth=5000.
----
The clone only has to be done once.
This will copy all the sources (including directories) from the server to your machine and check out the latest version.

The `-o upstream` flag uses the origin name “upstream” for the repository instead of the default “origin” as described in the https://docs.gitlab.com/ee/user/project/repository/forking_workflow.html[GitLab documentation].

Cloning may take some time depending on the speed of your internet connection.

The `--shallow-since=1year` option limits cloned commits to the last 1 year.

The `--depth=5000` option limits cloned commits to the last 5000.
--

[#ChSrcDevelopmentSnapshots]
==== Development Snapshots

This method is useful for one-off builds or if Git is inaccessible (e.g. because of a restrictive firewall).

Our GitLab CI configuration automatically generates development packages, including source packages.
They can be found at {wireshark-snapshots-url}.
Packages are available for recent commits in the master branch and each release branch.

[#ChSrcReleased]
==== Official Source Releases

This method is recommended for building downstream release packages.

The official source releases can be found at {wireshark-download-url}.
You should use these sources if you want to build Wireshark on your platform based on an official release with minimal or no changes, such as Linux distribution packages.

[#ChSrcUpdating]
=== Update Your Wireshark Sources

After you've obtained the Wireshark sources for the first time,
you might want to keep them in sync with the sources at the upstream
Git repository.

[TIP]
.Take a look at the recent commits first
====
As development evolves, the Wireshark sources are compilable most of the time -- but not always.
You should take a look at {wireshark-commits-url} before fetching or pulling to make sure the builds are in good shape.
====

[#ChSrcGitUpdate]
==== Update Using Git

From time to time you will likely want to synchronize your master branch with the upstream repository.
You can do so by running:

[source,sh]
----
$ git pull --rebase upstream master
----

[#ChSrcBuildFirstTime]
=== Build Wireshark

The sources contain several documentation files. It’s a good idea to read these
files first. After obtaining the sources, tools and libraries, the first place
to look at is _doc/README.developer_. Inside you will find the latest
information for Wireshark development for all supported platforms.

.Build Wireshark before changing anything
[TIP]
====
It is a very good idea to first test your complete build environment
(including running and debugging Wireshark) before making any changes
to the source code (unless otherwise noted).
====

Building Wireshark for the first time depends on your platform.

==== Building on Unix

Follow the build procedure in <<ChSetupUNIX>> to build Wireshark.

==== Windows Native

Follow the build procedure in <<ChSetupWindows>> to build Wireshark.

After the build process has successfully finished, you should find a
`Wireshark.exe` and some other files in the `run\RelWithDebInfo` directory.

[#ChSrcBuildType]
==== Build Type

CMake can compile Wireshark for several different build types:

.Build Types
|===
|Type |Compiler Flags |Description

|`RelWithDebInfo`
|`-O2 -g -DNDEBUG`
|Build with optimizations and generate debug symbols.
Disables assertions and disables debug level logs

|`Debug`
|`-g -DWS_DEBUG`
|For development, no optimization. Enables assertions and debug level logs

|`Release`
|`-O3 -DNDEBUG`
|Optimized for speed, no debug symbols or debug level logs or assertions

|`MinSizeRel`
|`-Os -DNDEBUG`
|Optimized for size, no debug symbols or debug level logs or assertions
|===

The default is `RelWithDebInfo`, which provides a good compromise of
some optimization (`-O2`) along with including debug symbols (`-g`)
for release builds. For normal development coding you probably want to be
using `Debug` build type or set -DENABLE_DEBUG=On, to enable full
<<ChSrcLogging,logging capabilities>> and debug code.

CMake will automatically add the -DNDEBUG option to certain build
types. This macro is used to disable assertions but it can be overruled
using ENABLE_ASSERT, which can be used to unconditionally enable assertions
if defined.

To change the build type, set the CMake variable `CMAKE_BUILD_TYPE`, e.g.:

[source,sh]
----
$ cmake .. -DCMAKE_BUILD_TYPE=Debug
----

or on Windows,

[source,cmd]
----
> msbuild /m /p:Configuration=Debug Wireshark.sln
----

[#ChSrcRunFirstTime]
=== Run Your Version Of Wireshark


[TIP]
.Beware of multiple Wiresharks
====
An already installed Wireshark may interfere with your newly generated
version in various ways. If you have any problems getting your Wireshark
running the first time, it might be a good idea to remove the previously
installed version first.
====

[#ChSrcRunFirstTimeUnix]
==== Unix-Like Platforms

After a successful build you can run Wireshark right from the `run` directory.
There's no need to install it first.

[source,sh]
----
$ ./run/wireshark
----

There’s no need to run Wireshark as root user, but depending on your platform you might not be able to capture.
Running Wireshark this way can be helpful since debugging output will be displayed in your terminal.
You can also change Wireshark’s behavior by setting various environment variables.
See the {wireshark-man-page-url}wireshark.html#ENVIRONMENT-VARIABLES[ENVIRONMENT VARIABLES] section of the Wireshark man page for more details.

On macOS, Wireshark is built as an application bundle (_run/Wireshark.app_) by default, and _run/wireshark_ will be a wrapper script that runs _Wireshark.app/Contents/MacOS/Wireshark_.
Along with running `./run/wireshark` as shown above you can also run it on the command line with `open run/Wireshark.app`.

[#ChSrcRunFirstTimeWindows]
==== Windows Native

By default the CMake-generated Visual {cpp} project places all of the files necessary to run Wireshark in the subdirectory `run\RelWithDebInfo`.
As with the Unix-like build described above, you can run Wireshark from the build directory without installing it first.

[source,cmd]
----
> .\run\RelWithDebInfo\Wireshark
----


[#ChSrcDebug]
=== Debug Your Version Of Wireshark

Optimization can make debugging a bit more difficult, e.g. by changing the
execution order of statements. To disable optimization, set the
<<ChSrcBuildType,build type>> to `Debug`.

Full debug logs can be invaluable to investigate any issues with the code.
By default debug level logs are only enabled with `Debug` build type. You
can enable full debug logs and extra debugging code by configuring the
ENABLE_DEBUG CMake option. This in turn will define the macro symbol
`WS_DEBUG` and enable the full range of debugging code in Wireshark.

There is an additional CMake knob called ENABLE_DEBUG_UTF_8 that can be used to
control specifically the extra validation Wireshark performs internally
for invalid UTF-8 encodings in internal strings, which should never happen
and can be somewhat expensive to check during normal usage.

Conversely, the `Release` or `MinSizeRel` build types can be used to optimize
further for speed or size, but do not include debug symbols for use with
debuggers, and completely disable <<ChSrcLoggingLevels,lower level logging>>
and asserts, optimizing away the code path. Ensure that you have not built with
one of those types before attempting debugging.

[#ChSrcLogging]
==== Wireshark Logging

Wireshark has a flexible logging system to assist in development and troubleshooting.
Logging configuration takes into account what, when and where to output diagnostic messages.

* The 'what generates log messages' is defined through logging domain(s).
* The 'when it generates log messages' is defined through the logging level.
* The 'where it outputs log messages' is defined through the output channel(s).

The details to configure and use the logging system are explained in the following sections.

[#ChSrcLoggingDomains]
===== Logging Domains

Any part of Wireshark can be assigned a logging domain. This is already done for most of the internals of Wireshark,
e.g., "Main", "Capture", "Epan", "GUI". The domains are defined in the `ws_log_defs.h` header but dissectors should
define their own logging domain. Any string can be used as ID for a logging domain.

[#ChSrcLoggingLevels]
===== Logging Levels

The following logging levels are defined from highest to lowest:

* error
* critical
* warning
* message
* info
* debug
* noisy

By default logging output is generated for logging level "message" and above. If the logging level is lowered or raised
all log output generated at or above this level is sent to the log output.
Note that if the <<ChSrcBuildType,build type>> is not set to `Debug`
then by default all log output for the logging levels "debug" and
"noisy" will be optimized away by the compiler and cannot be emitted to the log
output, regardless of the logging settings. To enable debug logging for all build
types, set the CMake variable `-DENABLE_DEBUG=ON`.

There is also a special "echo" logging level used exclusively for temporary debugging print outs (usually
via the `WS_DEBUG_HERE` macro).

[#ChSrcLoggingOutput]
===== Logging Output

By default logging output is sent to stderr. In addition to that it is possible to configure a log file. This collects all log output to the
file, besides the normal output streams. The output can then be read in a text editor or used with other text processing tools.

A program can also register its own log writer when the standard facilities are insufficient or special handling is required.

[#ChSrcConfigureLogging]
===== Configure Logging

Logging can be configured through either environment variables or command line parameters.

The following environment variables and command line parameters are used by the logging system:

WIRESHARK_LOG_DOMAIN, WIRESHARK_LOG_DOMAINS, or --log-domain, --log-domains::
This is a filter for the domain(s) which are to generate log messages.
WIRESHARK_LOG_LEVEL, or --log-level::
This is the level (below critical) for which log messages are to be generated. This is used for all configured domains.
WIRESHARK_LOG_DEBUG, or --log-debug::
These domain(s) will generate debug level log messages regardless of the log level and log domains configured.
WIRESHARK_LOG_NOISY, or --log_noisy::
These domain(s) will generate noisy level log messages regardless of the log level and log domains configured.

Multiple domains can be concatenated using commas or semicolons. The match can be inverted by prefixing the domain(s) list with an exclamation mark.

[#ChSrcTrapsLogging]
==== Traps Set By Logging

Sometimes it can be helpful to abort the program right after a log message of a certain level or a certain domain is output.

The following environment variables are used to configure a trap by the logging system:

WIRESHARK_LOG_FATAL, or --log_fatal::
This is the level for which log messages are fatal. This can either be "critical" or "warning" level.

WIRESHARK_LOG_FATAL_DOMAIN, WIRESHARK_LOG_FATAL_DOMAINS, or --log-fatal-domain, --log-fatal-domains::
These are the domain(s) where output of a log message is fatal. This is less commonly used than the fatal log level setting above.

[#ChSrcLoggingApi]
==== Logging APIs

The logging API can be found in `wsutil/wslog.h`.

To use the logging API for your code add the definition of the ID of your logging domain right after including `config.h`. For example:

[source,c]
----
/* My code doing something awesome */
#include "config.h"
#define WS_LOG_DOMAIN "MyCode"

#include <wireshark.h>

...
----

Populate your code with the applicable function calls to generate log messages when enabled. The following convenience macros are provided:

* `ws_error()`
* `ws_critical()`
* `ws_warning()`
* `ws_message()`
* `ws_info()`
* `ws_debug()`
* `ws_noisy()`

All these take `printf()` style parameters. There is also a `WS_DEBUG_HERE` macro that is always active and outputs to a special "echo"
domain for temporary debug print outs. `WS_DEBUG_HERE` should be used for development purposes only and not appear in final delivery of the code.

[#ChSrcUnixDebug]
==== Unix-Like Platforms

You can debug using command-line debuggers such as gdb, dbx, or lldb.
If you prefer a graphic debugger, you can use an IDE or debugging frontend
such as Qt Creator, CLion, or Eclipse.

Additional traps can be set on Wireshark, see <<ChSrcTrapsLogging>>

[#ChSrcMemorySafety]
===== Memory Safety and Leaks

Wireshark's wmem memory management framework makes it easy to allocate
memory in pools with a certain scope that is freed automatically at
a certain point (such as the end of dissecting a packet or when closing
a file), even if a dissector raises an exception after allocating the
memory. Memory in a pool is also freed collectively, which can be
considerably faster than calling `free()` individually on each individual
allocation. Proper use of wmem makes a dissector faster and less prone
to memory leaks with unexpected data, which happens frequently with
capture files.

However, wmem's block allocation can obscure issues that memory checkers
might otherwise catch. Fortunately, the `WIRESHARK_DEBUG_WMEM_OVERRIDE`
environment variable can be set at runtime to instruct wmem to use a specific
memory allocator for all allocations, some of which are more compatible with
memory checkers:

* `simple` - Uses `malloc()` only, no block allocation, compatible with Valgrind
* `strict` - Finds invalid memory via canaries and scrubbing freed memory
* `block` - Standard block allocator for file and epan scopes
* `block_fast` - Block allocator for short-lived scope, e.g. packet, (`free()` is a no-op)

The `simple` allocator produces the most accurate results with tools like
https://valgrind.org[Valgrind] and can be enabled as follows:

[source,sh]
----
$ export WIRESHARK_DEBUG_WMEM_OVERRIDE=simple
----

Wireshark uses GLib's GSlice memory allocator, either indirectly via wmem or via various GLib API calls.
GLib provides a `G_SLICE` environment variable that can be set to `always-malloc` (similar to `simple`) or `debug-blocks` (similar to `strict`).
See https://docs.gtk.org/glib/running.html for details.
The C libraries on FreeBSD, Linux, and macOS also support memory allocation debugging via various environment variables.
You can enable many of them by running `source tools/debug-alloc.env` in a POSIX shell.

If you're encountering memory safety bugs, you might want to build with
https://github.com/google/sanitizers/wiki/AddressSanitizer[Address Sanitizer]
(ASAN) so that Wireshark will immediately alert you to any detected issues.
It works with GCC or Clang, provided that the appropriate libraries are installed.

[source,sh]
----
$ cmake .. -G Ninja -DENABLE_ASAN=1
$ source ../tools/debug-alloc.env
$ ./run/tshark ...
----

TIP: ASAN slows things down by a factor of 2 (or more), so having a different
build directory for an ASAN build can be useful.

ASAN will catch more errors when run with either the `simple` or `strict`
wmem allocator than with the defaults. (It is more compatible with the
`strict` allocator and the analogous GSlice `debug-blocks` option than
Valgrind is.)

For additional instrumentation, ASAN supports a number of
https://github.com/google/sanitizers/wiki/AddressSanitizerFlags[options].

For further investigating memory leaks, the following can be useful:

[source,sh]
----
# This slows things down a lot more but results in more precise backtraces,
# especially when calling third party libraries (such as the C++ standard
# library):
$ export ASAN_OPTIONS=fast_unwind_on_malloc=0
# This causes LeakSanitizer to print the addresses of leaked objects for
# inspection in a debugger:
$ export LSAN_OPTIONS=report_objects=1
----

LeakSanitizer and AddressSanitizer can detect issues in third-party libraries
that you cannot do anything about. For example, internal Qt library calls to
the fontconfig library can produce leaks. To ignore them, create a
https://github.com/google/sanitizers/wiki/AddressSanitizerLeakSanitizer#suppressions[suppressions file] with an appropriate entry, e.g. `leak:libfontconfig`.

If you are just interested in memory safety checking, but not memory
leak debugging, disable the included https://github.com/google/sanitizers/wiki/AddressSanitizerLeakSanitizer[LeakSanitizer] with:

[source,sh]
----
$ export ASAN_OPTIONS=detect_leaks=0
----

[#ChSrcWindowsDebug]
==== Windows Native

You can debug using the Visual Studio Debugger or WinDbg.  See the section
on using the <<ChToolsDebugger, Debugger Tools>>.

[#ChSrcChange]
=== Make Changes To The Wireshark Sources

There are several reasons why you might want to change Wireshark’s sources:

* Add support for a new protocol (i.e., add a new dissector)

* Change or extend an existing dissector

* Fix a bug

* Implement a glorious new feature

Wireshark’s developers work on a variety of different platforms and use a variety of different development environments.
Although we don't enforce or recommend a particular environment, your editor should support https://editorconfig.org/[EditorConfig] in order to make sure you pick up the correct indentation style for any files that you might edit.

The internal structure of the Wireshark sources are described in <<PartDevelopment>>.

.Ask the {wireshark-dev-list-email} mailing list before you start a new development task.
[TIP]
====
If you have an idea what you want to add or change it’s a good idea to
contact the developer mailing list
(see <<ChIntroMailingLists>>)
and explain your idea. Someone else might already be working on the same
topic, so a duplicated effort can be reduced. Someone might also give you tips that
should be thought about (like side effects that are sometimes very
hard to see).
====

// XXX - Add a section on branching.

[#ChSrcContribute]
=== Contribute Your Changes

If you have finished changing the Wireshark sources to suit your needs, you might want to contribute your changes back to the Wireshark community.
You gain the following benefits by contributing your improvements:

.It’s the right thing to do.
Other people who find your contributions useful will appreciate them, and you will know that you have helped people in the same way that the developers of Wireshark have helped you.

.You get free enhancements.
By making your code public, other developers have a chance to make improvements, as there’s always room for improvements.
In addition someone may implement advanced features on top of your code, which can be useful for yourself too.

You save time and effort.
The maintainers and developers of Wireshark will maintain your code as well, updating it when API changes or other changes are made, and generally keeping it in tune with what is happening with Wireshark.
So if Wireshark is updated (which is done often), you can get a new Wireshark version from the website and your changes will already be included without any effort for you.

There’s no direct way to push changes to the {wireshark-gitlab-project-url}[main repository].
Only a few people are authorised to actually make changes to the source code (check-in changed files).
If you want to submit your changes, you should upload them to the code review system at {wireshark-code-review-url}.
This requires you to set up git as described at <<ChSrcGit>>.

[#ChSrcForkingWorkflow]
==== Workflow for Contributions

// To do:
// - Mention CLI utilities.

GitLab uses a https://docs.gitlab.com/ee/user/project/repository/forking_workflow.html[forking workflow], which looks like this:

.GitLab Workflow
image::images/git-triangular-workflow.svg[]

The major steps of the diagram above are:

* *Fork:* Create your own repository to work on.
You only need to do this once.

* *Pull:* You should pull from the main repository on a regular basis in order to ensure that your sources are current.

* *Push:* You should push any time you want to make a merge request or otherwise make your code public.

* *Merge Request:* submit your change to be included in the Wireshark project.

Let’s look at these steps in more detail.

[#ChSrcForkingTree]
==== Forking the Source Tree

First, you need to set up your environment.
For the steps below we’ll pretend that your username is “henry.perry”.

. Sign in to {wireshark-gitlab-project-url} by clicking “Sign in / Register” in the upper right corner of the web page and following the login instructions.

. https://docs.gitlab.com/ee/user/ssh.html[Add an SSH key to your account] as described in the GitLab documentation.

. Make sure you have a clone of the main repository as described in <<ChSrcGit>>.

. Create your own personal fork of the Wireshark project by https://docs.gitlab.com/ee/user/project/repository/forking_workflow.html[pressing the “Fork” button] at {wireshark-gitlab-project-url}.
+
--
WARNING: If you want to make merge requests you must keep your fork public.
Making it private will disassociate it from the main Wireshark repository.
--

. Add a remote for your personal repository in your source code checkout.
The main repository remote is named “upstream”, so we'll name this one “downstream”.
+
--
[source,sh]
----
$ git remote add downstream git@gitlab.com:henry.perry/wireshark.git
----
--

. Double-check your remotes:
+
--
[source,sh]
----
$ git remote -v
$ downstream	git@gitlab.com:henry.perry/wireshark.git (fetch)
$ downstream	git@gitlab.com:henry.perry/wireshark.git (push)
$ upstream	git@gitlab.com:wireshark/wireshark.git (fetch)
$ upstream	git@gitlab.com:wireshark/wireshark.git (push)
----
--

[#ChSrcPullingUpstream]
==== Pulling from Upstream

Before you begin it’s a good idea to synchronize your local repository with the main repository.
This is the *Pull* part of the workflow.
Simply re-run the command in <<ChSrcGitUpdate>>.
You should do this periodically in order to stay up to date and avoid merge conflicts later on.

////
// Is this unneeded extra confusion?
You can also tell GitLab to keep your fork up-to-date with the latest changes to the project:

. Visit your fork's home page at `\https://gitlab.com/henry.perry/wireshark`.
. In the left sidebar, under *Settings*, select *Repository* settings.
. Expand the section labelled *Mirroring repositories* and click btn:[Add new].
. For the URL, enter `\https://gitlab.com/wireshark/wireshark.git` ; leave the other settings at their defaults.
. Click btn:[Mirror repository].

--
NOTE: If you do this, GitLab will automatically update your fork with changes that are made upstream.
However, you will still need to update your local repository manually.
--

For more information about this GitLab feature, see https://docs.gitlab.com/ee/user/project/repository/mirror/index.html[their documentation].
////

[#ChSrcCreatingMergeRequests]
==== Creating Merge Requests

Now you’re ready to create a merge request (the *Push* and *Merge Request* parts of the workflow above).

. Create a branch for your change:
+
--
[source,sh]
----
$ git checkout -b my-glorious-new-feature upstream/master
----
--
+
--
NOTE: Always work from branches; never work directly on `master`.
It will be _much_ easier to keep abreast of upstream changes this way.
--

. Write some code!
See <<ChSrcGoodPatch>> and <<ChSrcCodeRequirements>> for details.

. Commit your changes.
See <<ChSrcGoodCommitMessage>> for details.
+
--
[source,sh]
----
$ git commit -a
----
--

. Push your changes to your personal repository.
+
--
[source,sh]
----
$ git push downstream HEAD
----
--

. Go to {wireshark-merge-request-url}.
You should see a https://docs.gitlab.com/ee/user/project/merge_requests/creating_merge_requests.html#create-merge-request-button[“Create merge request”] button.
Press it.

.. In the merge request page, make sure “Allow commits from members who can merge to the target branch” is selected so that core developers can rebase your change.
.. You might want to select “Delete source branch when merge request is accepted” as well.
.. Click the “Submit merge request” button.

// XXX Add command line instructions for one or more of the following:
// https://docs.gitlab.com/ee/user/project/push_options.html
// https://github.com/zaquestion/lab - Go (single binary).
// https://invent.kde.org/sdk/git-lab - Developed by the KDE team.
// https://github.com/vishwanatharondekar/gitlab-cli - Might work well for people who don't mind using NPM.


[#ChSrcUpdatingMergeRequests]
==== Updating Merge Requests

At this point various automated tests will be run and someone will review your change.
If you need to make changes you can do so by force-pushing it to the same branch in your personal repository.

. Make changes in your local repository.
+
--
[source,sh]
----
# First, make sure you're on the right branch.
$ git status
On branch my-glorious-new-feature
----
--

. Update your code.

. Rebuild and test your work to be sure it still does what it should.

. Push your changes to your personal repository.
+
--
[source,sh]
----
# Modify the current commit and force-push...
$ git commit --amend ...
$ git push downstream +HEAD
# ...or keep the current commit as-is add another commit on top of it
$ git commit ...
$ git push downstream HEAD
----
The `+` sign is shorthand for forcing the push (`-f`).
--

[#ChSrcRebasingMergeRequests]
===== Rebasing Merge Requests

The Wireshark upstream source code is likely to see other changes while you're doing your work.
Git allows you to adapt your in-progress work to these upstream updates, in a process known as _rebasing_.

Although GitLab provides a btn:[Rebase] button, you have more control over the process if you do it from the command line:

. Synchronize your local repository with the command from <<ChSrcGitUpdate>>.

. Switch back to your working branch: `git checkout my-glorious-new-feature`

. Rebase your working branch: `git rebase master`
+
--
TIP: At this stage you may experience a _merge conflict,_ which is when you've changed code which has also changed upstream.
The rebase will pause to allow you to resolve the conflict.
Once you've edited the code and reconciled the changes, resume the rebase with the command `git rebase --continue` .
--

. Rebuild and test your work to ensure it hasn't been adversely affected by the upstream changes.
(This is especially important if there were any merge conflicts.)

. Push your changes to your personal repository as described above.

[#ChSrcSquashingMergeRequests]
===== Squashing Merge Requests

When the Wireshark developer team is ready to accept your merge request, they may first ask you to _squash_ your changes.
This means taking all of the commits you've made on your working branch, and combining them into one commit.
Here's how to do it from the command line:

. Check out your working branch, if you aren't already on it.

. Run this command:
+
--
[source,sh]
----
# Perform an "interactive rebase"
$ git rebase -i master
----
--

. A text editor will appear, listing all of the commits that are in your branch.
Each commit will have the word “pick” at the start of the line.

. *Leave the first “pick” alone.* In every _following_ line replace “pick” with “squash”.

. Save your changes and exit your editor.

. A new editor will appear for you to tailor the commit message of the squashed commit.

. Once you're done, push your changes to your personal repository as described above.

[#ChSrcGoodPatch]
==== Some Tips For A Good Patch

Some tips that will make the merging of your changes into Git much more likely
(and you want exactly that, don't you?):

.Use the latest Git sources.
It’s a good idea to work with the same sources that are used by the other developers.
This usually makes it much easier to apply your patch.
For information about the different ways to get the sources, see <<ChSrcObtain>>.

.Update your sources just before making a patch.
For the same reasons as the previous point.

.Inspect your patch carefully.
Run `git diff` or `git show` as appropriate and make sure you aren't adding, removing, or omitting anything you shouldn't.

.Give your branch a brief but descriptive name.
Short, specific names such as _snowcone-machine-protocol_ are preferred.

.Don't put unrelated things into one large change.
Merge requests should be limited in scope.
For example, updates to the Snowcone Machine Protocol dissector and the Coloring Rules dialog box should be in separate merge requests.

In general, making it easier to understand and apply your patch by one of the maintainers will make it much more likely (and faster) that it will actually be applied.

.Thank you in advance for your patience.
Wireshark is a volunteer effort.
As a result, we can’t guarantee a quick turnaround time.

.Preview the final product.
Wireshark’s GitLab CI jobs are disabled by default for forks, but if you need to test any CI jobs you can do so under the “Pipelines” section in your repository.
For example, if your change might affect Debian (apt) packaging you can run the “build:debian-stable” job.

[#ChSrcGoodCommitMessage]
==== Writing a Good Commit Message

When running `git commit`, you will be prompted to describe your change.
Here are some guidelines on how to make that message more useful to other people (and to scripts that may try to parse it):

.Provide a brief description (under 60 characters or so) of the change in the first line.
If the change is specific to a single protocol, start this line with the abbreviated name of the protocol and a colon.
If the change is not yet complete prefix the line with “WIP:” to inform this change not to be submitted yet.
This be removed when the change is ready to be merged.

.Insert a single blank line after the first line.
This is required by various formatting tools and helpful to humans.

.Provide a detailed description of the change in the lines that follow.
Break paragraphs where needed.
Limit each line to 80 characters.

You can also reference and close issues in a commit message by prefixing the issue number with a https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#closing-issues-automatically[number sign].
For example, “closes #5” will close issue number 5.

Putting all that together, we get the following example:

[source]
----
MIPv6: Fix dissection of Service Selection Identifier

APN field is not encoded as a dotted string so the first character is not a
length. Closes #10323.
----

[#ChSrcCodeRequirements]

==== Code Requirements

To ensure Wireshark’s code quality and to reduce friction in the code review process, there are some things you should consider before submitting a patch:

.Follow the Wireshark source code style guide.
Wireshark runs on many platforms, and can be compiled with a number of different compilers.
It’s easy to write code that compiles on your machine, but doesn’t compile elsewhere.
The guidelines at <<ChCodeStyle>> describe the techniques and APIs that you can use to write high-quality, portable, and maintainable code in our environment.

.Submit dissectors as built-in whenever possible.
Developing a new dissector as a plugin can make compiling and testing quicker, but it’s usually best to convert it to built-in before submitting for review.
This reduces the number of files that must be installed with Wireshark and ensures your dissector will be available on all platforms.

Dissectors vary, so this is not a hard-and-fast rule.
Most dissectors are single C modules that can easily be put into “the big pile.”
Some (most notably ASN.1 dissectors) are generated using templates and configuration files.
Others are split across multiple source files and are often more suitable to be placed in a separate plugin directory.

.Ensure that the Wireshark Git Pre-Commit Hook is in the repository.
In your local repository directory, there will be a __.git/hooks/__ directory, with sample git hooks for running automatic actions before and after git commands.
You can also optionally install other hooks that you find useful.

In particular, the _pre-commit_ hook will run every time you commit a change and can be used to automatically check for various errors in your code.
The sample git pre-commit hook simply detects whitespace errors such as mixed tabs and spaces.
To install it just remove the .sample suffix from the existing _pre-commit.sample_ file.

Wireshark provides a custom pre-commit hook which does additional Wireshark-specific API and formatting checks, but it might return false positives.
If you want to install it, copy the pre-commit file from the tools directory (`cp ./tools/pre-commit .git/hooks/`) and make sure it is executable or it will not be run.

If the pre-commit hook is preventing you from committing what you believe is a valid change, you can run `git commit --no-verify` to skip running the hooks.
Warning: using --no-verify avoids the commit-msg hook, and thus if you have setup this hook it will not run.

Additionally, if your system supports symbolic links, as all UNIX-like platforms do, you can use them instead of copying files.
Running `ln -s ../../tools/pre-commit .git/hooks` creates a symbolic link that will make the hook to be up-to-date with the current master.

.Choose a compatible license.
Wireshark is released under the {spdx-license-url}GPL-2.0-or-later.html[GPL version 2 or later], and it is strongly recommended that incoming code use that license.
If that is not possible, it *must* use a compatible license.
The following licenses are currently allowed:

* BSD {spdx-license-url}BSD-1-Clause.html[1], {spdx-license-url}BSD-2-Clause.html[2], {spdx-license-url}BSD-3-Clause.html[3] clause
* {spdx-license-url}ISC.html[ISC]
* {spdx-license-url}LGPL-2.0-or-later.html[LGPL v2 or later], including {spdx-license-url}LGPL-2.1-or-later.html[v2.1]
* {spdx-license-url}MIT.html[MIT] / {spdx-license-url}X11.html[X11]
* {wikipedia-main-url}Public_domain[Public domain]
* {spdx-license-url}Zlib.html[zlib/libpng]

Notable incompatible licenses include {spdx-license-url}Apache-2.0.html[Apache 2.0], {spdx-license-url}GPL-3.0-or-later.html[GPL 3.0], and {spdx-license-url}LGPL-3.0-or-later.html[LGPL 3.0].

.Fuzz test your changes.
Fuzz testing is a very effective way of finding dissector related bugs.
In our case fuzzing involves making random changes to capture files and feeding them to TShark in order to try to make it crash or hang.
There are tools available to automatically do this on any number of input files.
See {wireshark-wiki-url}FuzzTesting for details.

[#ChSrcUpload]

////
==== Uploading your changes

When you're satisfied with your changes (and obtained any necessary
approval from your organization) you can upload them for review at
{wireshark-code-review-url}. This requires a GitLab account
as described at <<ChSrcGitRepository>>.

You need to fork your repository which will became yours, and you will have write access to it. Once
you are done with your changes, push them to a branch of your choice (as snowcone-machine). Now in the
GitLab's UI a message will tell you that you created a new branch and a button to create a merge request.


[source,sh]
----
$ git push https://gitlab.com/wireshark/<my.username>.git HEAD:<branchname>
----

The username `my.username` is the one which was given during registration with
the review system.

You can push using any Git client.

You might get one of the following responses to your patch request:

* Your patch is checked into the repository. Congratulations!

* You are asked to provide additional information, capture files, or other
  material. If you haven't fuzzed your code, you may be asked to do so.

* Your patch is rejected. You should get a response with the reason for
  rejection. Common reasons include not following the style guide, buggy or
  insecure code, and code that won't compile on other platforms. In each case
  you'll have to fix each problem and upload another patch.

* You don't get any response to your patch. Possible reason: All
  the core developers are busy (e.g., with their day jobs or family or other commitments) and
  haven't had time to look at your patch. Don't worry, if
  your patch is in the review system it won't get lost.

If you're concerned, feel free to add a comment to the patch or send an email
to the developer’s list asking for status. But please be patient: most if not
all of us do this in our spare time.
////

[#ChSrcBackport]
==== Backporting A Change

:example-branch: master-3.2
When a bug is fixed in the master branch it’s sometimes desirable or necessary to backport the fix to a release branch.
You can do this in Git by cherry-picking the change from one branch to another.
Suppose you want to backport change 1ab2c3d4 from the master branch to {example-branch}.
You can do so as follows:

[source,sh,subs="attributes+"]
----
# Create a new topic branch for the backport.
$ git checkout -b backport-1ab2c3d4 upstream/{example-branch}

# Cherry-pick the change. Include a "cherry picked from..." line.
$ git cherry-pick -x 1ab2c3d4

# If there are conflicts, fix them.

# Compile and test the change.
$ ninja
$ ...

# OPTIONAL: Add entries to doc/Wireshark_Release_Notes.adoc.
$EDITOR "doc/Wireshark_Release_Notes.adoc"

# If you made any changes, update your commit.
git commit --amend -a

# Push the change to your working repository.
git push downstream HEAD
----

You can also cherry-pick changes in the https://docs.gitlab.com/ee/user/project/merge_requests/cherry_pick_changes.html[GitLab web UI].

////
// XXX Is this relevant any more?
[#ChSrcPatchApply]
=== Apply a patch from someone else

Sometimes you need to apply a patch to your private source tree. Maybe
because you want to try a patch from someone on the developer mailing
list, or you want to check your own patch before submitting.


.Beware line endings
[WARNING]
====
If you have problems applying a patch, make sure the line endings (CR/LF)
of the patch and your source files match.
====

[#ChSrcPatchUse]
==== Using patch

Given the file _new.diff_ containing a unified diff,
the right way to call the patch tool depends on what the pathnames in
_new.diff_ look like.
If they're relative to the top-level source directory (for example, if a
patch to _prefs.c_ just has _prefs.c_ as the file name) you’d run it as:

[source,sh]
----
$ patch -p0 < new.diff
----

If they're relative to a higher-level directory, you’d replace 0 with the
number of higher-level directories in the path, e.g. if the names are
_wireshark.orig/prefs.c_ and
_wireshark.mine/prefs.c_, you’d run it with:

[source,sh]
----
$ patch -p1 < new.diff
----

If they're relative to a _subdirectory_ of the top-level
directory, you’d run `patch` in _that_ directory and run it with `-p0`.

If you run it without `-pat` all, the patch tool
flattens path names, so that if you
have a patch file with patches to _CMakeLists.txt_ and
_wiretap/CMakeLists.txt_,
it'll try to apply the first patch to the top-level
_CMakeLists.txt_ and then apply the
_wiretap/CMakeLists.txt_ patch to the top-level
_CMakeLists.txt_ as well.

At which position in the filesystem should the patch tool be called?

If the pathnames are relative to the top-level source directory, or to a
directory above that directory, you’d run it in the top-level source
directory.

If they're relative to a *subdirectory* -- for example,
if somebody did a patch to _packet-ip.c_ and ran `diff` or `git diff` in
the _epan/dissectors_ directory -- you’d run it in that subdirectory.
It is preferred that people *not* submit patches like
that, especially if they're only patching files that exist in multiple
directories such as _CMakeLists.txt_.
////

[#ChSrcBinary]

=== Binary Packaging

Delivering binary packages makes it much easier for the end-users to
install Wireshark on their target system. This section will explain how
the binary packages are made.

[#ChSrcVersioning]

==== Packaging Guidelines

The following guidelines should be followed by anyone creating and
distributing third-party Wireshark packages or redistributing official
Wireshark packages.

[discrete]
===== Spelling And Capitalization

Wireshark is spelled with a capital “W”, and with everything else lower
case. “WireShark” in particular is incorrect.

[discrete]
===== Main URL

The official Wireshark project URL is https://www.wireshark.org/.

[discrete]
===== Download URLs

Official packages are distributed on the main web server
(www.wireshark.org) and a
https://www.wireshark.org/download.html#spelunking[number of download
mirrors]. The canonical locations for packages are in the _all_versions_
subdirectories on each server.

For example, if your packaging system links to or downloads the
source tarball and you want to download from 1.na.dl.wireshark.org,
use

https://1.na.dl.wireshark.org/download/src/all-versions/wireshark-{wireshark-version}.tar.xz

instead of

https://1.na.dl.wireshark.org/download/src/wireshark-{wireshark-version}.tar.xz

[discrete]
===== Staying Current

Wireshark releases are announced on the link:{wireshark-mailing-lists-url}[wireshark-announce] mailing list.
A https://appvisor.com/pad/[PAD] file is also published at https://www.wireshark.org/wireshark-pad.xml which contains the current stable version and release date.

[discrete]
===== Artwork

Logo and icon artwork can be found in the _resources_ directory in the
distribution. This is available online at

{wireshark-code-browse-url}/resources

[discrete]
===== Licensing

Wireshark is released under the GNU General Public License version 2 or
later. Make sure you and your package comply with this license.

[discrete]
===== Trademarks

Wireshark, Stratoshark, and their respective “fin” logos are trademarks of the link:{wireshark-foundation-url}[Wireshark Foundation].
If you have any questions about the use of these trademarks, please contact the foundation.

[discrete]
===== Privileges

All function calls that require elevated privileges are in dumpcap.

WIRESHARK CONTAINS MILLIONS AND MILLIONS OF LINES OF SOURCE CODE.
DO NOT RUN THEM AS ROOT.

Warnings are displayed when Wireshark and TShark are run as root.

There are two <<ChToolsCMake,configure-time options>> on non-Windows
systems that affect the privileges a normal user needs to capture
traffic and list interfaces:

-DDUMPCAP_INSTALL_OPTION=capabilities::
Install dumpcap with cap_net_admin and cap_net_raw capabilities. Linux
only.

-DDUMPCAP_INSTALL_OPTION=suid::
Install dumpcap setuid root.

These are necessary for non-root users to be able to capture on most
systems, e.g. on Linux or FreeBSD if the user doesn't have permissions
to access /dev/bpf*. Setcap installation is preferred over setuid on
Linux. If `-DDUMPCAP_INSTALL_OPTION=capabilities` is used it will
override any setuid settings.

The `-DENABLE_CAP` option is only useful when dumpcap is installed
setuid. If it is enabled dumpcap will try to drop any setuid privileges
it may have while retaining the `CAP_NET_ADMIN` and `CAP_NET_RAW`
capabilities. It is enabled by default, if the Linux capabilities
library (on which it depends) is found.

Note that enabling setcap or setuid installation allows packet capture
for ALL users on your system. If this is not desired, you can restrict
dumpcap execution to a specific group or user. The following two examples
show how to restrict access using setcap and setuid respectively:

[source,sh]
----
# groupadd -g packetcapture
# chmod 750 /usr/bin/dumpcap
# chgrp packetcapture /usr/bin/dumpcap
# setcap cap_net_raw,cap_net_admin+ep /usr/bin/dumpcap

# groupadd -g packetcapture
# chgrp packetcapture /usr/bin/dumpcap
# chmod 4750 /usr/bin/dumpcap
----

[discrete]
===== Customization

Custom version information can be added by running
`tools/make-version.py`. If your package contains significant changes we
recommend that you use this to differentiate it from official Wireshark
releases.

[source, sh]
----
tools/make-version.py --set-release --untagged-version-extra=-{vcsinfo}-FooCorp --tagged-version-extra=-FooCorp .
----

See `tools/make-version.py` for details.

The Git version corresponding to each release is in _version.h_. It's
defined as a string. If you need a numeric definition, let us know.

If you have a question not addressed here, please contact
{wireshark-dev-list-email}.


[#ChSrcDeb]

==== Debian: .deb Packages

The Debian Package is built using dpkg-buildpackage, based on information found in the source tree under _packaging/debian_.
You must create a top-level symbolic link to _packaging/debian_ before building.
See https://www.debian.org/doc/manuals/maint-guide/build.en.html for a more in-depth discussion of the build process.


In the wireshark directory, type:

[source,sh]
----
ln -snf packaging/debian
export DEB_BUILD_OPTIONS="nocheck"
dpkg-buildpackage -b -us -uc -jauto
----

to build the Debian Package.

[#ChSrcRpm]

==== Red Hat: .rpm Packages

You can build an RPM package using the `wireshark_rpm` target. If you
are building from a git checkout, the package version is derived from
the current git HEAD. If you are building from source extracted from a
tarball created with `git archive` (such as those downloaded from
http://www.wireshark.org/download.html), you must place the original
tarball into your build directory.

The package is built using https://rpm.org/[rpmbuild], which comes as
standard on many flavours of Linux, including Red Hat, Fedora, and
openSUSE. The process creates a clean build environment in
_$\{CMAKE_BINARY_DIR}/packaging/rpm/BUILD_ each time the RPM is built.
The settings that control the build are in
_$\{CMAKE_SOURCE_DIR}/packaging/rpm/wireshark.spec.in_. The generated
SPEC file contains CMake flags and other settings for the RPM build
environment. Many of these come from the parent CMake environment.
Notable ones are:

* _prefix_ is set to _CMAKE_INSTALL_PREFIX_. By default this is
  _/usr/local_. Pass `-DCMAKE_INSTALL_PREFIX=/usr` to create a package
  that installs into _/usr_.

* Whether or not to create the “wireshark-qt” package
  (`-DBUILD_wireshark`).

* Lua, c-ares, nghttp2, and other library support (`-DENABLE_...`).

* Building with Ninja (`-G Ninja`).

In your build directory, type:

[source,sh]
----
ninja wireshark_rpm
# ...or, if you're using GNU make...
make wireshark_rpm
----

to build the binary and source RPMs. When it is finished there will be a
message stating where the built RPM can be found.

.This might take a while
[TIP]
====
This creates a tarball, extracts it, compiles Wireshark, and constructs
a package. This can take quite a long time. You can speed up the process
by using Ninja. If you're using GNU make you can add the following to
your `~/.rpmmacros` file to enable parallel builds:

----
%_smp_mflags -j %(grep -c processor /proc/cpuinfo)
----
====

Building the RPM package requires quite a few packages and libraries
including GLib, `gcc`, `flex`, Asciidoctor, and Qt development
tools such as `uic` and `moc`. The required Qt packages can usually be
obtained by installing the _qt6-qt*-devel_ packages. For a complete list of
build requirements, look for the “BuildRequires” lines in
_packaging/rpm/wireshark.spec.in_.

[#ChSrcOSX]

==== macOS: .dmg Packages

The macOS Package is built using macOS packaging tools, based on information found in the source tree under _packaging/macosx_.
It requires https://asciidoctor.org/[Asciidoctor] and https://pypi.org/project/dmgbuild/[dmgbuild].

In your build directory, type:

[source,sh]
----
ninja wireshark_dmg stratoshark_dmg # (Modify as needed)
# ...or, if you're using GNU make...
make wireshark_dmg stratoshark_dmg # (Modify as needed)
----

to build the macOS Packages.

[#ChSrcNSIS]

==== Windows: NSIS .exe Installer

The _Nullsoft Install System_ is a free installer generator for Windows systems.
Instructions on installing it can be found in <<ChToolsNSIS>>.
NSIS is script based. You can find the main Wireshark installer generation script at _packaging/nsis/wireshark.nsi_.

When building with CMake you must first build the _wireshark_nsis_prep_ target, followed by the _wireshark_nsis_ target, e.g.

[source,cmd]
----
> msbuild /m /p:Configuration=RelWithDebInfo wireshark_nsis_prep.vcxproj
> msbuild /m /p:Configuration=RelWithDebInfo wireshark_nsis.vcxproj
----

Splitting the packaging projects in this way allows for code signing.

[TIP]
.This might take a while
====
Please be patient while the package is compressed.
It might take some time, even on fast machines.
====

If everything went well, you will now find something like:
_wireshark-setup-{wireshark-version}.exe_ in
the _packaging/nsis_ directory in your build directory.

[#ChSrcPortableApps]

==== Windows: PortableApps .paf.exe Package

_PortableApps.com_ is an environment that lets users run popular applications
from portable media such as flash drives and cloud drive services.

* Install the _PortableApps.com Platform_. Install for “all users”, which
will place it in `C:\PortableApps`.  +

* Add the following apps:

** PortableApps.com Installer
** PortableApps.com Launcher

When building with CMake you must first build the _wireshark_nsis_prep_ target
(which takes care of general packaging dependencies), followed by the
_wireshark_portableapps_ target, e.g.

[source,cmd]
----
> msbuild /m /p:Configuration=RelWithDebInfo wireshark_nsis_prep.vcxproj
> msbuild /m /p:Configuration=RelWithDebInfo wireshark_portableapps.vcxproj
----

[TIP]
.This might take a while
====
Please be patient while the package is compressed.
It might take some time, even on fast machines.
====

If everything went well, you will now find something like:
_WiresharkPortable64{underscore}{wireshark-version}.paf.exe_ in
the _packaging/portableapps_ directory.

[#ChSrcMimeTypes]

=== Mime Types

Wireshark uses various mime-types for dragging dropping as well as file formats.
This chapter gives an overview over all the mimetypes being used, as well as the
data format in which data has to be provided for each individual mimetype.

If not otherwise stated, the data is encoded as a JSON Object.

==== Display Filter

**MimeType**: application/vnd.wireshark.displayfilter

Display filters are being dragged and dropped by utilizing this mime type.

[source,json]
----
{
        "filter": "udp.port == 8080",
        "field": "udp.port",
        "description": "UDP Port"
}
----

==== Coloring Rules

**MimeType**: application/vnd.wireshark.coloringrules

Coloring Rules are being used for dragging and dropping color rules inside the
coloring rules dialog.

[source,json]
----
{
        "coloringrules" :
        [
                {
                        "disabled": false,
                        "name": "UDP Ports for 8080",
                        "filter": "udp.port == 8080",
                        "foreground": "[0x0000, 0x0000, 0x0000]",
                        "background": "[0xFFFF, 0xFFFF, 0xFFFF]"
                }
        ]
}
----

==== Filter List

**MimeType**: application/vnd.wireshark.filterlist

*_Internal Use only_* - used on the filter list for moving entries within the
list

==== Column List

**MimeType**: application/vnd.wireshark.columnlist

*_Internal Use only_* - used on the column list for moving entries within the
list


// End of WSDG Chapter Sources

// vim: set syntax=asciidoc:
