Remove the endpoint map and its button from the Qt and GTK+ UIs. It
depends on GeoIP Legacy for coordinate information and those databases
are being deprecated in favor of MaxMind DB. We *could* upgrade the code
to use mmdbresolve, but according to
https://dev.maxmind.com/geoip/geoip2/geolite2/ they're also going to
remove coordinate information from GeoLite2:
"In addition, in 2019, latitude and longitude coordinates in the
GeoLite2 databases will be removed.* Latitude and longitude coordinates
will continue to be provided in GeoIP2 databases. Please check back for
updates."
Change-Id: I43e1593d282a0f1aae897b1f4724117d1496b21e
Reviewed-on: https://code.wireshark.org/review/26229
Petri-Dish: Gerald Combs <gerald@wireshark.org>
Tested-by: Petri Dish Buildbot
Reviewed-by: Gerald Combs <gerald@wireshark.org>
Set the API target level to Win7, along with installer changes
to match.
Change-Id: Icd93964eadf93018c56218e3efdfed10b9f8959a
Reviewed-on: https://code.wireshark.org/review/26218
Reviewed-by: Graham Bloice <graham.bloice@trihedral.com>
This codec plugin serves a dual purpose.
First it is to add L16 codec suppport to Wireshark.
Second it is an illustration of a basic codec plugin module.
Change-Id: I64394dab3257ae49dece0257b16cd969503918e2
Reviewed-on: https://code.wireshark.org/review/26131
Reviewed-by: Jaap Keuter <jaap.keuter@xs4all.nl>
Petri-Dish: Jaap Keuter <jaap.keuter@xs4all.nl>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
See if that makes it possible for CrashReporter to fully symbolicate
crash dumps, so the user gets line numbers and the like in crash dumps
from the OS, and we get them if the user sends a crash dump to us.
Change-Id: I8bb48b2d2f6b3e23fea43c1a3bd3a5a9a97a5c2c
Reviewed-on: https://code.wireshark.org/review/26123
Reviewed-by: Guy Harris <guy@alum.mit.edu>
There's no Wireshark.app/Contents/Resources/bin directory; remove the
variable containing its path, and the part of an error message that
refers to it.
Change-Id: Id41cc00a2671925c50b2075dd3e9d0f84d5bd921
Reviewed-on: https://code.wireshark.org/review/26039
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Instead of using the never-defined $binpath (undefined going back to at
least Wireshark 1.0.0 - is it a leftover from the Inkscape version?),
use $bundle_binary_list, to strip all the executables with strip -ur.
(Not that we want to strip anything - we don't even want the debugging
symbols stripped! - but for cleanliness.)
Change-Id: I9c3520ffb418bf9dc206d3ccb55d347c208f3be2
Reviewed-on: https://code.wireshark.org/review/26033
Reviewed-by: Guy Harris <guy@alum.mit.edu>
We no longer have the code to create a bundle, as we rely on CMake
having done so, at least to the extent of populating the bundle with all
the files we've generated. Get rid of the code that used to support it,
and the command-line options that are no longer necessary now that we no
longer build code bundles.
Don't have explicit lists of CLI or extcap binaries; instead, just look
for all plain files in Wireshark.app/Contents/MacOS that have read and
execute permissions for owner/group/user. That way, we don't have to
update the script if we add new binaries or new directories of binaries.
Change-Id: I047296a7889bea71165eebde10f34bec6ea96cc5
Reviewed-on: https://code.wireshark.org/review/26032
Reviewed-by: Guy Harris <guy@alum.mit.edu>
It may find files that aren't Mach-O binary files. Instead, rename
cs_binary_list to bundle_binary_list, and use it when checking for
dependencies as well as when code-signing binaries.
Change-Id: I9d17a4ba137e494fbd38db1b62f5cc7e4b620fc9
Reviewed-on: https://code.wireshark.org/review/26028
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Just use "find" to find plain files under $pkglib and $pkgexec; this
avoids trying to run otool on directories, which can cause it to stop
looking in $pkgexec/* past the extcap directory, and does try to run it
on the Qt frameworks in subdirectories under $pkglib.
Add a comment giving more details about the big command to find
dependencies.
Change-Id: Ife3c3a8493ca0b6ea28f1bb108f63714366abeed
Reviewed-on: https://code.wireshark.org/review/26003
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Unstripped binaries should allow better stack traces in the
CrashReporter files.
Change-Id: Idb2f11cd664dc62331f3394dee09abcd4e88f897
Reviewed-on: https://code.wireshark.org/review/25977
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Some versions of otool print the file name as the first line when you
run it with -hv, so that the line containing the file type is the fourth
line; others don't print it, so that it's the third line. Instead, look
for the line that has MH_MAGIC.
Change-Id: Ib14f6b24f14069532263332e53a1e9895663641a
Reviewed-on: https://code.wireshark.org/review/25968
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Look in %VCToolsRedistDir% for the redistributable that we ship with
the NSIS installer. Clarify a couple of status messages.
Change-Id: I965d15947c3d3422d7c722afa581f4f7dfc2725a
Reviewed-on: https://code.wireshark.org/review/25804
Petri-Dish: Gerald Combs <gerald@wireshark.org>
Tested-by: Petri Dish Buildbot
Reviewed-by: Gerald Combs <gerald@wireshark.org>
Add "%VCToolsRedistDir%\MergeModules" to the merge module search path.
This is required for Visual Studio 2017 here.
Change-Id: I91cd1527ae80c85ed304c1233436cae52aa0a501
Reviewed-on: https://code.wireshark.org/review/25782
Reviewed-by: Gerald Combs <gerald@wireshark.org>
Petri-Dish: Gerald Combs <gerald@wireshark.org>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Stuff that calls it is built in, and stuff it calls is built in, so
there's not much point in having it be a plugin; we already have
examples of plugin dissectors.
Change-Id: I512e0fda62faedb5f03f476fbece2e267e1d644f
Reviewed-on: https://code.wireshark.org/review/25775
Petri-Dish: Guy Harris <guy@alum.mit.edu>
Tested-by: Petri Dish Buildbot
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Switch the markup text processor for files in the docbook directory from
AsciiDoc to Asciidoctor. Asciidoctor has several useful features (such
as direct PDF output) and is actively developed. It's written in Ruby
but that dependency can be sidestepped with AsciidoctorJ, a
self-contained bundle that only depends on the JRE.
The current toolchain targets require Python, AsciiDoc, DocBook XML,
DocBook XSL, Java, FOP, xsltproc, lynx, and the HTMLHelp compiler:
HTML: AsciiDoc → DocBook XML → xsltproc + DocBook XSL
Chunked HTML: AsciiDoc → DocBook XML → xsltproc + DocBook XSL
PDF: AsciiDoc → DocBook XML → xsltproc + DocBook XSL → FOP
HTMLHelp: AsciiDoc → DocBook XML → xsltproc + DocBook XSL → HHC
This change removes the AsciiDoc and FOP requirements and adds either
AsciidoctorJ or Asciidoctor + Ruby:
HTML: Asciidoctor → DocBook XML → xsltproc + DocBook XSL
Chunked HTML: Asciidoctor → DocBook XML → xsltproc + DocBook XSL
PDF: Asciidoctor
HTMLHelp: Asciidoctor → DocBook XML → xsltproc + DocBook XSL → HHC
Ideally we could generate all of these using AsciidoctorJ, Java, and
lynx. Unfortunately we're not there yet.
The release notes depend on several macros (ws-buglink, ws-salink,
cve-idlink, sort-and-group). Add Asciidoctor (Ruby) equivalents.
Remove the BUILD_xxx_GUIDES CMake options and add various output targets
automatically. This means that you have to build the various documentation
targets explicitly.
Change-Id: I31930677a656b99b1c6839bb6c33a13db951eb9a
Reviewed-on: https://code.wireshark.org/review/25668
Petri-Dish: Gerald Combs <gerald@wireshark.org>
Tested-by: Petri Dish Buildbot
Reviewed-by: Gerald Combs <gerald@wireshark.org>
The first is deprecated, as per https://spdx.org/licenses/.
Change-Id: I8e21e1d32d09b8b94b93a2dc9fbdde5ffeba6bed
Reviewed-on: https://code.wireshark.org/review/25661
Petri-Dish: Anders Broman <a.broman58@gmail.com>
Petri-Dish: Dario Lombardo <lomato@gmail.com>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
That way we don't have to change the script if we add new plugin
subdirectories.
Change-Id: Ic788807c723306e461b7c1f8721b48a46d4fff96
Reviewed-on: https://code.wireshark.org/review/25584
Reviewed-by: Guy Harris <guy@alum.mit.edu>
We now have "epan" and "wiretap" subdirectories of the plugin directory,
with the first containing libwireshark plugins and the second containing
libwiretap plugins. Look for plugins in those directories, rather than
in the top-level plugin directory.
Bug: 14389
Change-Id: Ia3bd4d27e82215207e7a7dcfc8f91042bbc61737
Reviewed-on: https://code.wireshark.org/review/25577
Reviewed-by: Guy Harris <guy@alum.mit.edu>
This wiretap plugin serves a dual purpose. One is to add usbdump file
reading capability to wiretap and therefore Wireshark and Tshark.
Second it is an illustration of a basic wiretap plugin module.
Change-Id: Iefbb156ea1bc5d90dabc1753942cdb9e393714ad
Signed-off-by: Jaap Keuter <jaap.keuter@xs4all.nl>
Reviewed-on: https://code.wireshark.org/review/25487
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Some oddities with regard to file permissions have crept into
the repository. Reset execute rights on various files which do
not need them.
Change-Id: Ib05658072925d59fc682173673c5638d157a269a
Signed-off-by: Jaap Keuter <jaap.keuter@xs4all.nl>
Reviewed-on: https://code.wireshark.org/review/25490
Reviewed-by: Guy Harris <guy@alum.mit.edu>
We handle translations in QtTranslation.wxs so we need to skip them when
generating QtDependentComponents.wxs.
Change-Id: I05586c7f8fbbaf72fc30564a157ba1175154d1d3
Reviewed-on: https://code.wireshark.org/review/25459
Reviewed-by: Gerald Combs <gerald@wireshark.org>
Make plugins.c the source of truth for plugin names. Where plugins
reside and what they do are two different things, so split the plugin
directory and description into two separate elements.
CMake creates portable[1] builds on Windows and macOS. That is, the
build-time directory layout is the same as the installation directory
layout. Adjust various plugin paths macOS accordingly.
[1] You have to run osx-app.sh on macOS to prepare the application
bundle, but the goal is to create a directory/bundle that can be moved
or copied to a different system and run in the new location.
Change-Id: Icf9d02e61918fdf1404468baf52542910edf2743
Reviewed-on: https://code.wireshark.org/review/25166
Petri-Dish: Gerald Combs <gerald@wireshark.org>
Tested-by: Petri Dish Buildbot
Reviewed-by: Gerald Combs <gerald@wireshark.org>
At one point, I remember a discussion resulting in the official name of
the next-generation replacement for pcap format being changed to
"pcapng", with no hyphen.
Make Wireshark reflect that.
Change-Id: Ie66fb13a0fe3a8682143106dab601952e9154e2a
Reviewed-on: https://code.wireshark.org/review/25214
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Put different types of plugins (libwiretap, libwireshark) in different
subdirectories, give libwiretap and libwireshark init routines that
load the plugins, and have them scan the appropriate subdirectories
so that we don't even *try* to, for example, load libwireshark plugins
in programs that only use libwiretap.
Compiled plugins are stored in subfolders of the plugin folders, with
the subfolder name being the Wireshark minor version number (X.Y). There is
another hierarchical level for each Wireshark library (libwireshark, libwscodecs
and libwiretap).
The folder names are respectively plugins/X.Y/{epan,codecs,wiretap}.
Currently we only distribute "epan" (libwireshark) plugins.
Change-Id: I3438787a6f45820d64ba4ca91cbe3c8864708acb
Reviewed-on: https://code.wireshark.org/review/23983
Petri-Dish: João Valverde <j@v6e.pt>
Tested-by: Petri Dish Buildbot
Reviewed-by: João Valverde <j@v6e.pt>
This sets the scope of the static build option to Wireshark support
libraries only.
Before the patch:
Static plugins don't work with CMake and autotools.
autotools static build is broken, and most likely will always be, as
building Wireshark all-static is difficult and time-consuming.
After the patch:
For CMake Wireshark will be built with static or shared libraries and
dynamic plugins. Everything just works. CMake apparently doesn't want
you building static and shared libraries at the same time.
For autotools Wireshark will be built with shared libraries by default.
--disable-shared and --enable-static options work as usual. Dlopened
plugins are not built if --disable-shared is given to configure (to
disable shared libraries). This is a limitations imposed by libtool.
Tested on Linux. This removes broken support for building plugins
statically.
Change-Id: Ib8e8176976f136eea93a2ce8f9857b6cf9bec64c
Reviewed-on: https://code.wireshark.org/review/24241
Petri-Dish: João Valverde <j@v6e.pt>
Tested-by: Petri Dish Buildbot
Reviewed-by: João Valverde <j@v6e.pt>
Change-Id: I480e58a1676677bb362bb4e9dc866c5d5f0814e1
Reviewed-on: https://code.wireshark.org/review/24111
Reviewed-by: Jeff Dyer <jmasterfunk@gmail.com>
Reviewed-by: Michael Mann <mmann78@netscape.net>
Set NTDDI_VERSION and _WIN32_WINNT to their Vista values so that
ws2tcpip.h will define inet_pton and inet_ntop. Remove the associated
compiler version checks so that everyone is on the same page.
Add breadcrumbs to the various parts of the code where we set a minimum
Windows version.
Change-Id: I83bba5fa1024bfbc02e07b120412807ad259e291
Reviewed-on: https://code.wireshark.org/review/24080
Petri-Dish: Gerald Combs <gerald@wireshark.org>
Reviewed-by: Michael Mann <mmann78@netscape.net>
Reviewed-by: Gerald Combs <gerald@wireshark.org>
There's only so much we can/should do here, so dispense with the _topdir
test.
Change-Id: Ibf1170ea2cbb7c536df901db42d67da668fd64b2
Reviewed-on: https://code.wireshark.org/review/23912
Reviewed-by: João Valverde <j@v6e.pt>
Rename osx-app.sh to osx-app.sh.in and add the version to the plugin
path at configure time.
Instead up updating Autotools accordingly just remove the macOS
packaging targets. gf61c381b5a removed support for Autotools in
osx-app.sh and if anyone wants to build macOS packages I'd prefer that
they use the same toolchain as the buildbot.
Change-Id: Ide5205265bf8859a85b1afab68fa8f8285952bd3
Reviewed-on: https://code.wireshark.org/review/23839
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Remove Autotools-specific code from osx-app.sh. The official builders
have used CMake for a while and as far as I know no one else uses our
packaging scripts.
Change-Id: I6fc20114b42e10dacc69346c379055b68184b85c
Reviewed-on: https://code.wireshark.org/review/23833
Reviewed-by: Anders Broman <a.broman58@gmail.com>
rpathify_dir is not recursive so the plugin path fix in g94af9724d1
wasn't sufficient. Make sure $pkgplugin is set to the versioned plugin
subdirectory so that both rpathification and code signing work.
Find the Qt frameworks directory using qmake while we're here. This
should be more reliable than calling pkg-config (which doesn't work on
my laptop).
Bug: 14096
Change-Id: I0196015f849fd27994a439359cddd88c21106fde
Reviewed-on: https://code.wireshark.org/review/23832
Reviewed-by: Gerald Combs <gerald@wireshark.org>
Remove the svr4-package and solaris-package targets along with their
associated files and directories. We used to use this to build Solaris
packages but we haven't shipped those in years. Given that the last
substantive change to packaging/svr4 was in 2008 it's likely that this
has been unused for a while.
Change-Id: Ib9153c99f503200ea8c48d3ef81ad688ee55c09f
Reviewed-on: https://code.wireshark.org/review/23808
Petri-Dish: Gerald Combs <gerald@wireshark.org>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
... not to be confused with "machine-to-machine".
M2M seems to be a simple Wimax encapsulation protocol developed by Intel.
It's not documented publicly anywhere that I can find. The boilerplate to
code ratio is huge and it even includes a complete source file from the Wimax
dissector (yuck). Put it in the Wimax plugin instead.
Minor version number bump for wimax plugin.
Change-Id: I2694339dfe89be334093b257a5b34d1577f4dc20
Reviewed-on: https://code.wireshark.org/review/23790
Petri-Dish: João Valverde <j@v6e.pt>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Exclude .exp and .lib files when we run xcopy.
Change-Id: I913a1360507a8812a678efcd35d9afe58167d11b
Reviewed-on: https://code.wireshark.org/review/23777
Reviewed-by: Gerald Combs <gerald@wireshark.org>
Gerald Combs