The Wireshark Wiki at https://wiki.wireshark.org provides a wide range
of information related to Wireshark and packet capturing in general.
You will find a lot of information not part of this developer's guide. For
example, there is an explanation how to capture on a switched network,
an ongoing effort to build a protocol reference and a lot more.
And best of all, if you would like to contribute your knowledge on a
specific topic (maybe a network protocol you know well), you can edit the
wiki pages by simply using your webbrowser.
The "Frequently Asked Questions" will list often asked questions and
the corresponding answers.
Read the FAQ!
Before sending any mail to the mailing lists below, be sure to read the
FAQ, as it will often answer the question(s) you might have. This will save
yourself and others a lot of time (keep in mind that a lot of people are
subscribed to the mailing lists).
You will find the FAQ inside Wireshark by clicking the menu item
Help/Contents and selecting the FAQ page in the upcoming dialog.
An online version is available at the Wireshark website:
https://www.wireshark.org/faq.html. You might
prefer this online version, as it's typically more up to date and the HTML
format is easier to use.
1.7.4. Other sources
If you don't find the information you need inside this book, there are
various other sources of information:
the file doc/README.developer and
all the other README.xxx files in the source code - these are various
documentation files on different topics
the Wireshark source code
tool documentation of the various tools used
(e.g. manpages of sed, gcc, ...)
There are several mailing lists available on specific Wireshark topics:
This mailing list will inform you about new program
releases, which usually appear about every 4-8 weeks.
This list is for users of Wireshark. People post
questions about building and using Wireshark, others (hopefully)
This list is for Wireshark developers. People post questions about
the development of Wireshark, others (hopefully) provide answers.
If you want to start developing a protocol dissector, join this list.
This list is for Wireshark developers. Every time a change to the bug
database occurs, a mail to this mailing list is generated.
If you want to be notified about all the changes to the bug
database, join this list. Details about the bug database can be
found in Section 1.7.6, “Bug database (Bugzilla)”.
This list is for Wireshark developers. Every time a change to the SVN
repository is checked in, a mail to this mailing list is generated.
If you want to be notified about all the changes to the SVN
repository, join this list. Details about the SVN repository can be
found in Section 3.2, “The Wireshark Subversion repository”.
You can subscribe to each of these lists from the Wireshark web site:
select the mailing lists link on the left hand
side of the site. The lists are archived at the Wireshark web site
You can search in the list archives to see if someone previously asked the same
question and maybe already got an answer. That way you
don't have to wait until someone answers your question.
1.7.6. Bug database (Bugzilla)
The Wireshark community collects bug reports in a Bugzilla database at
This database is filled with manually filed bug reports, usually after some
discussion on wireshark-dev, and bug reports from the QA build tools.
1.7.7. Reporting Problems
Before reporting any problems, please make sure you have installed the
latest version of Wireshark.
If you report problems, provide as much
information as possible. In general, just think about what
you would need to find that problem, if someone else sends you such a
problem report. Also keep in mind that people compile/run Wireshark on a lot of different
When reporting problems with Wireshark, it is helpful if you supply the
The version number of Wireshark and the dependent libraries linked with
it, e.g. GTK+, etc. You can obtain this with the command
Information about the platform you run Wireshark on.
A detailed description of your problem.
If you get an error/warning message, copy the text of that message (and
also a few lines before and after it, if there are some), so others may
find the build step where things go wrong.
Please don't give something like: "I get a warning when compiling x"
as this won't give any direction to look at.
Don't send large files!
Do not send large files (>100KB) to the mailing lists, just place a note
that further data is available on request. Large files will only annoy a
lot of people on the list who are not interested in your specific problem.
If required, you will be asked for further data by the persons who really
can help you.
Don't send confidential information!
If you send captured data to the mailing lists, or add it to your bug report,
be sure it doesn't contain any sensitive or confidential information,
such as passwords.
Type the characters in the first line verbatim! Those are
backtrace is a gdb command. You should
enter it verbatim after the first line shown above, but it will not be
echoed. The ^D
(Control-D, that is, press the Control key and the D key
together) will cause gdb to exit. This will
leave you with a file called
bt.txt in the current directory.
Include the file with your bug report.
If you do not have gdb available, you
will have to check out your operating system's debugger.
The Windows distributions don't contain the symbol files (.pdb), because
they are very large. For this reason it's not possible to create
a meaningful backtrace file from it. You should report your crash just
like other problems, using the mechanism from
Section 1.7.7, “Reporting Problems”.