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].
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 their documentation.
Git is a fast, flexible way of managing source code. It allows large scale distributed development and ensures data integrity.
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.
Wireshark originally used Concurrent Versions System (CVS) and migrated to Subversion in July 2004. We migrated from Subversion to Git and 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.
Like most revision control systems, Git uses branching to manage different copies of the source code and allow parallel development. Wireshark uses the following branch naming conventions:
Main feature development and odd-numbered development releases.
Stable release maintenance. For example, release-3.4 is used to manage the 3.4.x official releases.
Tags for major releases and release candidates consist of a “v” followed by a version number such as “v3.2.1” or “v3.2.3rc0”. Major releases additionally have a tag prefixed with “wireshark-” followed by a version number, such as “wireshark-3.2.0”.
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.
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.
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 Contribute Your Changes 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
gitworks:$ 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:
$ git config --global user.name "Henry Perry" $ git config --global user.email henry.perry@example.com -
Next, clone the Wireshark repository:
# 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 upstreamflag uses the origin name “upstream” for the repository instead of the default “origin” as described in the GitLab documentation.Cloning may take some time depending on the speed of your internet connection.
The
--shallow-since=1yearoption limits cloned commits to the last 1 year.The
--depth=5000option limits cloned commits to the last 5000.
This method is useful for one-off builds or if Git is inaccessible (e.g. because of a restrictive firewall).
The Buildbot server 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.
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.
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 Buildbot first
As development evolves, the Wireshark sources are compilable most of the time — but not always. You should take a look at {wireshark-buildbot-url} before fetching or pulling to make sure the builds are in good shape. |
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.
|
Tip
|
Build Wireshark before changing anything
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.
Follow the build procedure in [ChSetupUNIX] to build Wireshark.
Follow the build procedure in [ChSetupWin32] 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.
|
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. |
After a successful build you can run Wireshark right from the run directory.
There’s no need to install it first.
$ ./run/wiresharkThere’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.
By default the CMake-generated Visual C++ 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.
> .\run\RelWithDebInfo\WiresharkYou 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 by setting the WIRESHARK_LOG_FATAL
environment variable:
$ WIRESHARK_LOG_FATAL=critical gdb wiresharkIf you’re encountering memory safety bugs, you might want to build with Address Sanitizer so that Wireshark will immediately alert you to any detected issues.
$ cmake .. -G Ninja -DENABLE_ASAN=1You can debug using the Visual Studio Debugger or WinDbg. See the section on using the Debugger Tools.
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 we don’t enforce or recommend a particular environment, your editor should support 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].
|
Tip
|
Ask the {wireshark-dev-list-email} mailing list before you start a new development task.
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). |
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:
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.
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 Git Over SSH Or HTTPS.
GitLab uses a forking workflow, which looks like this:
In the diagram above, your fork can created by pressing the “Fork” button at {wireshark-gitlab-project-url}. Your local repository can be created as described in Git Over SSH Or HTTPS. You only need to do this once. You should pull from the main repository on a regular basis in order to ensure that your sources are current. You should push any time you want to make a merge request or otherwise make your code public. The “Pull”, “Push”, and “Merge Request” parts of the workflow are important, so let’s look at them in more detail.
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.
-
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 Git Over SSH Or HTTPS.
-
Create your own personal fork of the Wireshark project by pressing the “Fork” button at {wireshark-gitlab-project-url}.
-
Add a remote for your personal repository. The main repository remote is named “upstream”, so we’ll name this one “downstream”.
$ git remote add downstream git@gitlab.com:henry.perry/wireshark.git
-
Double-check your remotes:
$ 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)
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. You should do this periodically in order to stay up to date and avoid merge conflicts later on.
-
Fetch and optionally apply the latest changes.
# Fetch changes from upstream and apply them to the current branch... $ git pull --rebase upstream master # ...or fetch changes and leave the current branch alone $ git fetch upstream
Now you’re ready to create a merge request (the Push and Merge Request parts of the workflow above).
-
First, create a branch for your change:
$ git checkout -b my-glorious-new-feature upstream/master
-
Write some code! See Some Tips For A Good Patch and Code Requirements for details.
-
Commit your changes. See Writing a Good Commit Message for details.
$ git commit -a
-
Push your changes to your personal repository.
$ git push downstream HEAD
-
Go to {wireshark-merge-request-url}. You should see a “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.
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.
-
Push your changes to your personal repository.
# First, make sure you're on the right branch. $ git status On branch my-glorious-new-feature -
Update your code.
-
Push your changes to your personal repository.
# 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).
Some tips that will make the merging of your changes into Git much more likely (and you want exactly that, don’t you?):
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 Obtaining The Wireshark Sources.
For the same reasons as the previous point.
Run git diff or git show as appropriate and make sure you aren’t adding, removing, or omitting anything you shouldn’t.
Short, specific names such as snowcone-machine-protocol are preferred.
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.
Wireshark is a volunteer effort. As a result, we can’t guarantee a quick turnaround time.
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.
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):
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.
This is required by various formatting tools and helpful to humans.
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 number sign. For example, “closes #5” will close issue number 5.
Putting all that together, we get the following example:
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.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:
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.
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.
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.
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}GPL-3.0-or-later.html[GPL version 3 or later] with the Bison parser exception
-
{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 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.
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 master-3.2. You can do so as follows:
# Create a new topic branch for the backport.
$ git checkout -b backport-g1ab2c3d4 upstream/master-3.2
# 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 docbook/release-notes.adoc.
$EDITOR docbook/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 HEADYou can also cherry-pick changes in the GitLab web UI.
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.
The following guidelines should be followed by anyone creating and distributing third-party Wireshark packages or redistributing official Wireshark packages.
Wireshark is spelled with a capital “W”, and with everything else lower case. “WireShark” in particular is incorrect.
The official Wireshark project URL is https://www.wireshark.org/.
Official packages are distributed on the main web server (www.wireshark.org) and a 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
instead of
Logo and icon artwork can be found in the image directory in the distribution. This is available online at
{wireshark-code-browse-url}/image
Wireshark is released under the GNU General Public License version 2 or later. Make sure you and your package comply with this license.
Wireshark and the “fin” logo are registered trademarks of the Wireshark Foundation. Make sure you and your package comply with trademark law.
All function calls that require elevated privileges are in dumpcap.
WIRESHARK CONTAINS OVER THREE MILLION LINES OF SOURCE CODE. DO NOT RUN THEM AS ROOT.
Warnings are displayed when Wireshark and TShark are run as root.
There are two 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:
# 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/dumpcapCustom version information can be added by running
tools/make-version.pl. If your package contains significant changes we
recommend that you use this to differentiate it from official Wireshark
releases.
tools/make-version.pl --set-release --untagged-version-extra=-{vcsinfo}-FooCorp --tagged-version-extra=-FooCorpSee tools/make-version.pl 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}.
The Debian Package is built using dpkg-buildpackage, based on information found in the source tree under debian. 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:
dpkg-buildpackage -b -us -uc -jautoto build the Debian Package.
You can build an RPM package using the rpm-package target. The package
version is derived from the current git HEAD, so you must build from a
git checkout.
The package is built using 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=/usrto 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:
ninja rpm-package
# ...or, if you're using GNU make...
make rpm-packageto build the binary and source RPMs. When it is finished there will be a message stating where the built RPM can be found.
|
Tip
|
This might take a while
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 %_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 qt5-devel package. For a complete list of
build requirements, look for the “BuildRequires” lines in
packaging/rpm/wireshark.spec.in.
The macOS Package is built using macOS packaging tools, based on information found in the source tree under packaging/macosx. It requires Asciidoctor and dmgbuild.
In your build directory, type:
ninja dmg_package
# ...or, if you're using GNU make...
make dmg_packageto build the macOS Package.
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 nsis_package_prep target, followed by the nsis_package target, e.g.
> msbuild /m /p:Configuration=RelWithDebInfo nsis_package_prep.vcxproj
> msbuild /m /p:Configuration=RelWithDebInfo nsis_package.vcxprojSplitting 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.
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:
-
NSIS Portable (Unicode)
-
PortableApps.com Installer
-
PortableApps.com Launcher
-
PortableApps.com AppCompactor
When building with CMake you must first build the nsis_package_prep target (which takes care of general packaging dependencies), followed by the portableapps_package target, e.g.
> msbuild /m /p:Configuration=RelWithDebInfo nsis_package_prep.vcxproj
> msbuild /m /p:Configuration=RelWithDebInfo portableapps_package.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{wireshark-version}.paf.exe_ in the packaging/portableapps directory.
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.
MimeType: application/vnd.wireshark.displayfilter
Display filters are being dragged and dropped by utilizing this mime type.
{
"filter": "udp.port == 8080",
"field": "udp.port",
"description": "UDP Port"
}MimeType: application/vnd.wireshark.coloringrules
Coloring Rules are being used for dragging and dropping color rules inside the coloring rules dialog.
{
"coloringrules" :
[
{
"disabled": false,
"name": "UDP Ports for 8080",
"filter": "udp.port == 8080",
"foreground": "[0x0000, 0x0000, 0x0000]",
"background": "[0xFFFF, 0xFFFF, 0xFFFF]"
}
]
}MimeType: application/vnd.wireshark.filterlist
Internal Use only - used on the filter list for moving entries within the list