MaxMind is discontinuing its legacy databases in April in favor of
GeoIP2, which use a newer database format (MaxMind DB). The reference C
library (libmaxminddb) is available under the Apache 2.0 license which
isn't quite compatible with ours.
Add mmdbresolve, a utility that reads IPv4 and IPv6 addresses on stdin
and prints resolved information on stdout. Place it under a liberal
license (MIT) so that we can keep libmaxminddb at arm's length. Add
epan/maxmind_db.[ch], which spawns mmdbresolve and communicates with it
via stdio.
Migrate the preferences and documentation to MaxMindDB.
Change the IPv4 and IPv6 asnum fields to FT_UINT32s. Change the
geographic coordinate fields to FT_DOUBLEs.
Bug: 10658
Change-Id: I24aeed637bea1b41d173270bda413af230f4425f
Reviewed-on: https://code.wireshark.org/review/26214
Petri-Dish: Gerald Combs <gerald@wireshark.org>
Tested-by: Petri Dish Buildbot
Reviewed-by: Gerald Combs <gerald@wireshark.org>
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>
This reverts commit 3cfa4f7602.
Nope, *not* needed, and not wanted, either.
Change-Id: I71ac174a9b9b19980d0a6f44088d0a66f71ef99b
Reviewed-on: https://code.wireshark.org/review/19538
Reviewed-by: Guy Harris <guy@alum.mit.edu>
We can't just symbolically link to the executables, as that means that
the executable won't be in Contents/MacOS, which means that all
@executable_path-relative references will go to the wrong place if we
run the executables using the symlink, which means that the executables
could fail (they *do* fail to find the Cocoa Qt plugin, for example).
So, instead, we go back to the old version of the utility launcher, and
put that in Contents/Resources/bin as well as, if the user requests the
CLI utilities, /usr/local/bin. Maybe PackageMaker will find that
acceptable and include them in the installer package.
Bug: 13270
Change-Id: I4016b58c9ce0df05d78525d35e53431750c2b4d9
Reviewed-on: https://code.wireshark.org/review/19536
Reviewed-by: Guy Harris <guy@alum.mit.edu>
PackageMaker appears not to put them into the installer package, so
construct them in the Wireshark post-install script.
Bug: 13270
Change-Id: Idfa10d4d123d2c0e2f7b3ad65888e075fbfd27a7
Reviewed-on: https://code.wireshark.org/review/19531
Reviewed-by: Guy Harris <guy@alum.mit.edu>
That way, $PATH points to .../Wireshark.app/Contents/Resources/bin, so
the man command will look in
.../Wireshark.app/Contents/Resources/share/man.
This also may obviate the need to install the wrapper scripts in
/usr/local/bin, although those scripts obviate the need to re-set PATH
after installing Wireshark.
Change-Id: I7202b5a0fe5d2b90c956dc0db2af073f6c08b00d
Reviewed-on: https://code.wireshark.org/review/19296
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Do for executables what we do for man pages.
Change-Id: I066f0199fd6064cae21e6ad079a1f344e1002c66
Reviewed-on: https://code.wireshark.org/review/18205
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Modify postinstall.sh script to add file /etc/manpaths.d/Wireshark
during installation.
Content of the file is the current path of the Wireshark manpages.
Bug: 12746
Change-Id: I1dc0dc9a2acf56c39c78c709294f1a6804c6ec5c
Reviewed-on: https://code.wireshark.org/review/17916
Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Michael Mann <mmann78@netscape.net>
That way, if we crash in the middle, there's still something installed
that will try to set the permissions on the BPF devices.
Change-Id: Ie0c32f9eaca08bdbb359d07e47f20c664bc66411
Reviewed-on: https://code.wireshark.org/review/2023
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Only one is necessary; get rid of the startup item.
Change-Id: I0bd2dabb3fc286ccd0e6634bc112e20602624c86
Reviewed-on: https://code.wireshark.org/review/2016
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Add a cli-preinstall script that creates missing parts of the
installation path and sets their permissions. Simply copy
"utility-launcher" to "wireshark" instead of renaming it at install
time. Explicitly set its ownership and permissions. Pretty-print some of
the PackageMaker XML files via `xmllint --format --recover`.
svn path=/trunk/; revision=53281
PackageMaker would be a more correct fix. Replacing PackageMaker with
something that fits our development and deployment model would be an
even more correct fix.
svn path=/trunk/; revision=37167
Gerald Combs