Description:
============
DECT pcap files can be obtained by using tools included with the linux
kernel driver for the Dosch-and-Amand COM-ON-AIR cards. The driver is
called com-on-air_cs.

Wireshark cannot directly record from the DECT HW, as the driver
currently lacks a virtual network interface.

There is ongoing work to change this (see this work by Patrick McHardy):
git clone git://git.kernel.org/pub/scm/linux/kernel/git/kaber/dect-2.6.git
git clone git://git.kernel.org/pub/scm/linux/kernel/git/kaber/libnl-dect.git
git clone git://git.kernel.org/pub/scm/libs/netlink/libnl.git
Also needed are a proper linktype value assigned by the libpcap team and
the proper patches for libpcap to support this (the value used in the
patch below is not officially assigned!):
git://git.kernel.org/pub/scm/linux/kernel/git/kaber/libpcap-dect.git

To nicely view DECT pcap files in wireshark, set up a custom layout:

Edit->Preferences...
  User Interface
    Colums

      No.      | Number
      Protocol | Protocol
      Frame    | Custom Column: dect.framenumber
      TA       | Custom Column: dect.cc.TA
      A-Field  | Custom Column: dect.cc.AField
      B-Field  | Custom Column: dect.cc.BField
  OK


Edit->Configuration Profiles...
  New
  Profile Name = dect
  OK

libpcap 0.7.1 and later appear to work on AIX when using AIX's native
BPF; that appears to work better than DLPI does.  Note that you may have
to run AIX's tcpdump, as root, before configuring, building, and
installing libpcap, in order to create the "/dev/bpf" devices and load
the BPF driver.

However, libpcap 0.7.1 doesn't work perfectly with AIX's BPF - it
appears that AIX's BPF devices inform their user that packets were
dropped since the last successful read by returning -1 and setting
"errno" to EFAULT, which libpcap 0.7.1 treats as an error.  The current
CVS version of libpcap ignores EFAULT on AIX; it appears that this fixes
the problem.

Some earlier notes:

The notes about libpcap may not apply, with libpcap 0.7.1 and later, but
they're preserved here for historical reasons.

The notes about glib, gtk+, and Ethereal may not apply, as we're now
using GLib 2.x and GTK+ 2.x, and don't have our own gtkclist.c, but
they're also preserved for historical reasons.

After much work and toil, Craig Rodrigues was able to compile libpcap
and Ethereal on AIX 4.3.2.  His odyssey is document in various e-mails
at https://www.wireshark.org/lists/ethereal-dev/199911/

Here are a few excerpts.  Note that, to configure "libpcap" to use DLPI
rather than BPF (which it'll apparently use by default on AIX),
specifying the flag

	--with-pcap=dlpi

to the "configure" script for "libpcap" should do the trick.

The source code changes to Ethereal mentioned below should be in the
current source tree.  The changes to the GLib configure script is in
GLib 1.2.7; the changes for the "-lgdk" problem are probably still
necessary in the current version of GTK+.

Subject: Re: [ethereal-dev] Re: [ethereal-users] Problems compiling 0.7.7 under AIX 4.3.2
From: Gilbert Ramirez <gram@xiexie.org>
Date: Fri, 5 Nov 1999 16:58:17 -0600
To: Guy Harris <guy@netapp.com>
Cc: Craig Rodrigues <rodrigc@mediaone.net>, ethereal-dev@zing.org


On Fri, Nov 05, 1999 at 01:42:44PM -0600, Guy Harris wrote:
>
>
> Hmm.
>
> Looks suspiciously similar to the previous error; have you tried
> recompiling GTK+ with "xlc_r"?

I believe glib and gtk+ should both be compiled with xlc_r. I haven't
compiled on AIX in a long time, but I think it's because glib is including
pthread stuff, so the re-entrant C library, libc_r, is needed.


Compiler Invocation

When compiling a multi-threaded program, you should invoke the C compiler
using one of the following commands:

xlc_r
    Invokes the compiler with default language level of ansi.
cc_r
    Invokes the compiler with default language level of extended.


These commands ensure that the adequate options and libraries are used to be
compliant with the X/Open Version 5 Standard. The POSIX Threads
Specification 1003.1c is a subset of the X/Open Specification.

The following libraries are automatically linked with your program when using these commands:

libpthreads.a
	    Threads library.
libc.a
	    Standard C library


For example, the following command compiles the foo.c multi-threaded C source file and produces the foo executable file:

cc_r -o foo foo.c

See the cc command for more information about C For AIX.


--gilbert


To: ethereal-users@zing.org
Subject: [ethereal-dev] AIX: gtk problem solved, now an ethereal problem
From: Craig Rodrigues <rodrigc@mediaone.net>
Date: Mon, 8 Nov 1999 10:46:25 -0500
Cc: ethereal-dev@zing.org


Hi,

After much sweat and toil, I have managed to get gtk 1.2.6 to
compile and not dump core under AIX.  The solutions were to
(1) apply the attached patch to the configure.ac in the glib-1.2.6
subdirectory

(2)  In the file gtk+-1.2.6/gtk/Makefile, add a link flag -lgdk to link
in gdk.

I have submitted (1) to the gtk-devel mailing list where it has been
accepted.  (2) is an uglier problem, but for now, adding -lgdk by hand
seems to work.

Now I have a problem....I compiled gtk, and that works.
I compiled ethereal (after some minor mods), and it starts,
but when I click on Capture -> Start, I get:

"There are no network interfaces that can be opened."

I am running as root, so I don't think permissions are a problem.

Any ideas?

Thanks.
--
Craig Rodrigues
http://www.gis.net/~craigr
rodrigc@mediaone.net

*** configure.ac.old    Thu Oct  7 17:27:43 1999
--- configure.ac        Sun Nov  7 19:34:36 1999
***************
*** 795,809 ****
	  fi
	  if test "$ac_cv_func_getpwuid_r" = "yes"; then
		  AC_MSG_CHECKING(whether getpwuid_r is posix like)
!                       # getpwuid_r(0, NULL, NULL, 0) is the signature on
!                       # solaris, if that is not found, the prog below won't
!                       # compile, then the posix signature is assumed as
!                       # the default.
!                       AC_TRY_COMPILE([#include <pwd.h>],
!                               [getpwuid_r(0, NULL, NULL, 0);],
!                               [AC_MSG_RESULT(no)],
!                               [AC_MSG_RESULT(yes)
!                               AC_DEFINE(HAVE_GETPWUID_R_POSIX)])
	  fi
  fi
  if test x"$have_threads" = xposix; then
--- 795,809 ----
	  fi
	  if test "$ac_cv_func_getpwuid_r" = "yes"; then
		  AC_MSG_CHECKING(whether getpwuid_r is posix like)
!                       # The signature for the POSIX version is:
!                       # int getpwuid_r(uid_t, struct passwd *, char *, size_t, struct passwd **)
!                       AC_TRY_COMPILE([#include <pwd.h>
!                                         #include <sys/types.h>
!                                         #include <stdlib.h>],
!                               [getpwuid_r((uid_t)0, NULL, NULL, (size_t)0, NULL);],
!                               [AC_DEFINE(HAVE_GETPWUID_R_POSIX)
!                               AC_MSG_RESULT(yes)],
!                               [AC_MSG_RESULT(no)])
	  fi
  fi
  if test x"$have_threads" = xposix; then



To: ethereal-dev@zing.org
Subject: Re: [ethereal-dev] AIX: gtk problem solved, now an ethereal problem
From: Craig Rodrigues <rodrigc@mediaone.net>
Date: Wed, 10 Nov 1999 12:18:47 -0500



Hi,

OK, I'm getting closer and closer to this working on AIX.

Things I've done:

(1) In a bunch of places in the code I removed '//' style C++ comments
which the IBM C compiler didn't like.

(2) I also found some places in the code like:

enum some_enum {  FOO, BAR, };

IBM C did not like the trailing "," after BAR.

(3) In packet-ipv6.h, IPV6_VERSION is defined, but that is already
defined in <netinet/in.h> on AIX 4.3, so for now I just commented that out.

(4) in packet-afs.c, when it sucks in <netinet/in.h>,  in.h sucks in
<sys/machine.h> which defines LITTLE_ENDIAN.  This conflicts with
LITTLE_ENDIAN in globals.h.  So what I did was, in globals.h, I added:

#ifdef HAVE_NETINET_IN_H
#include <netinet/in.h>
#endif

So after doing all these things, I can compile ethereal and run it.
I can list the
correct network interfaces on my system: lo0 and en0.  However,
when I start capturing packets on en0, they are all of the protocol type
"TRMAC" and "TR".  The only problem is, I'm not on a Token Ring network.

Any ideas?

No. Time        Source                Destination           Protocol   Info
1 0.000000    0a:30:a1:08:00:45     06:74:60:08:00:5a     TR   Token-Ring Unknown
2 0.210304    0a:30:a1:08:00:45     06:74:60:08:00:5a     TR   Token-Ring Unknown
3 0.926080    0a:30:a1:08:00:45     06:74:60:08:00:5a     TR   Token-Ring Unknown
4 0.4236416   0a:30:a1:08:00:45     06:74:60:08:00:5a     TR   Token-Ring Unknown
5 0.4712064   6f:06:74:60:08:00     5a:8a:30:a1:00:00 TR MAC Unknown Major Vector: 127


---------------------
It turns out that libpcap was using IFT_* numbers instead of DLT_* numbers for
link types. That has been fixed
---------------------


To: tcpdump-workers@tcpdump.org
Subject: [ethereal-dev] Sucess with libpcap under AIX
From: Craig Rodrigues <rodrigc@mediaone.net>
Date: Sat, 20 Nov 1999 03:34:50 -0500
Cc: ethereal-dev@zing.org


Hi,

I have managed to successfully compile and use the latest
snapshot of libpcap under AIX using DLPI.  bpf is majorly
brain-dead under AIX, and very unsupported.  Rather than
find all the bugs in AIX's bpf, I decided to try using
dlpi, which is officially supported.

The first step is to get the setup right.  To determine if
you have the dlpi driver loaded correctly, type:
strload -q -d dlpi

If the result is:
dlpi: yes

then you are ready to use dlpi.

If you get:
dlpi: no

Then you need to type:
strload -f /etc/dlpi.conf

Check again with strload -q -d dlpi that the dlpi driver is loaded.

I had to make one minor code change to pcap-dlpi.c.  Maybe someone
can explain it to me, because I am not familiar with dlpi or
streams programming.  It took me hours to figure this out, because
I'm not familiar with dlpi.

In pcap-dlpi.c, lines 316-320:
#if !defined(HAVE_HPUX9) && !defined(HAVE_HPUX10_20) && !defined(sinix)
       if (dlbindreq(p->fd, 0, ebuf) < 0 ||
	   dlbindack(p->fd, (char *)buf, ebuf) < 0)
	    goto bad;
#endif

I changed it to:
#if !defined(HAVE_HPUX9) && !defined(HAVE_HPUX10_20) && !defined(sinix)
       if (dlbindreq(p->fd, 1620, ebuf) < 0 ||
	   dlbindack(p->fd, (char *)buf, ebuf) < 0)
	    goto bad;
#endif

I picked the number 1620 out of thin air.  The second parameter
to dlbindreq() sets the value of dl_sap.  This dl_sap
value is then passed along to the DLPI driver through
the DL_BIND_REQ primitive.  I guess that it cannot be 0 under
AIX, but I'm not sure.

If someone knows anything about DLPI, I'd appreciate a clarification.
Basically, I am just using the DLPI specification at:
http://www.opengroup.org/onlinepubs/009638599/ which is pretty good.
The AIX documentation is not so well written.

But basically, after I fixed up pcap-dlpi.c, I managed to get libpcap
working under AIX.  This enabled me to successfully run Ethereal,
ie. all the packets on my Ethernet network correctly showed up
as Ethernet and not Token Ring in the Wireshark screen.

YAY!
--
Craig Rodrigues
http://www.gis.net/~craigr
rodrigc@mediaone.net

Date: Thu, 11 Nov 1999 23:47:02 -0500
From: Craig Rodrigues <rodrigc@mediaone.net>
To: ethereal-dev@zing.org
Subject: Re: [ethereal-dev] AIX: gtk problem solved, now an ethereal  problem

On Thu, Nov 11, 1999 at 11:50:23AM -0800, Guy Harris wrote:
> > The only differences between gtkclist.c in the gtk distribution and
> > gtkclist.c in the ethereal distribution relate to the ROW_ELEMENT
> > macro.  It looks like an optimization for retrieving the GList item
> > when the requested row is the last row in the list.
>
> Yup - as per my other mail, Ethereal does that rather a lot when
> building the CList, and the optimization changes quadratic behavior to
> linear behavior.
>
> > Any ideas why this causes trouble?
>
> Mismatches between the layouts of data structures as declared in the
> "gtk/gtk*.h" files in the Wireshark source tree and the layouts as
> declared in the header files in the GTK+ source (either due to header
> file differences - although the header files appear to be identical to
> the GTK+ 1.2.6 ones - or due to compiler behavior differences)?

I tried stepping things through the debugger, and constantly
hit the same segfault inside gdk_string_width(), line 308 of gdkfont.c

Fails on line: switch(font->type),
where *font is: (type = -1, ascent = -1, descent = -1)

Stack trace:
gdk_string_width(font = 0x7caf01a4, string = "../"), line 308 in "gdkfont.c"
gtk_file_selection_populate(fs = 0x20094468, rel_path = "", try_complete = 0), line 1341 in "gtkfilesel.c"
gtk_file_selection_init(filesel = 0x20094468), line 513 in "gtkfilesel.c"
gtk_type_new(0xc315), line 403 in "gtktypeutils.c"
gtk_file_selection_new(title = "Ethereal: Open Capture File"), line 524 in "gtkfilesel.c"
file_open_cmd_cb(0x200640f4, 0x0), line 79 in "file_dlg.c"

Removing gtkclist.o from libui.a and recompiling removed this problem.

Any ideas?  I'm stumped.

--
Craig Rodrigues
http://www.gis.net/~craigr
rodrigc@mediaone.net

Installing Wireshark on FreeBSD/OpenBSD/NetBSD/DragonFly BSD
========================================================================

     1. Extra packages required
     2. Compiling Wireshark
     3. Berkeley Packet Filter (BPF) requirement
     4. Running Wireshark as a non-root user


1. Extra packages required
---------------------------
Wireshark requires a number of additional programs to function.
Install the latest versions of the following programs before compiling:

The easiest way to install these is by using your operating system's
ports or packages system.  If you prefer to build from source, the programs
can be found at the following sites:

    glib 2.32 or later:
         ftp.gnome.org:/pub/gnome/sources/glib/
	 http://ftp.gnome.org/pub/gnome/sources/glib/

    pkgconfig:
         http://pkgconfig.freedesktop.org/releases/

    python 3.4 or later:
         https://www.python.org/downloads/source/

If you want to use the Wireshark GUI, install one or both of these toolkits:

    Qt 5.3 or later:
	 http://download.qt-project.org/official_releases/qt/


(These programs may require additional dependencies)

Additional programs can be used to enhance Wireshark's functionality.
These can be found by typing ./configure --help or looking at the output
at the end of running the configure script.


2. Compiling Wireshark
-----------------------
To compile Wireshark with the default options, run configure, make and
make install (you may have to run "autogen.sh" first):

     ./configure
     make
     make install

The configure and make steps can be run as a non-root user and you can
run Wireshark from the compilation directory itself.  You must run make
install as root in order to copy the program to the proper directories.


3. Berkeley Packet Filter (BPF) requirement
--------------------------------------------
In order to capture packets (with Wireshark/TShark, tcpdump, or any
other packet capture program) on a BSD system, your kernel must have the
Berkeley Packet Filter mechanism enabled.  The default kernel
configurations in recent versions of BSD systems have this enabled
already.  To verify the bpf device is present, look in the /dev
directory:

    ls -l /dev/bpf*

You should see one or more bpf devices listed similar to this:

    crw-------  1 root  wheel    0,  90 Aug 10 21:05 /dev/bpf0
    crw-------  1 root  wheel    0,  91 Aug 10 21:05 /dev/bpf1

Packet-capturing programs will pick the first bpf device that's not in
use.  Recent versions of most BSDs will create bpf devices as needed, so
you don't have to configure the number of devices that will be
available.

4. Running wireshark as a non-root user
-------------------------------------------
Since the bpf devices are read-only by the owner (root), you normally
have to run packet capturing programs such as Wireshark as root.  It is
safer to run programs as a non-root user if possible.  To run Wireshark
as a non-root user, you must change the permissions on the bpf device(s).
If you are the only user that needs to use Wireshark, the easiest way
is to change the owner of each bpf device to your username.  You can also
add the read/write ability to the group (typically wheel) and add users
that need to use Wireshark to the wheel group.  Check your operating
system's documentation on how to make permanent these changes as they
are often reset upon reboot; if /dev is implemented with devfs, it might
be possible to configure devfs to create all bpf devices owned by a
particular user and/or group and with particular permissions.  In
FreeBSD 6.0 and later this can be done by creating an /etc/devfs.rules
file with content such as

	[localrules=10]
	add path 'bpf*' {mode and permissions}

where "mode and permissions" can include clauses such as

	mode {octal permissions}

to set the permissions on the device (e.g., "mode 0660" to set the
permissions to rw-rw-r--),

	user {user}

to set the user who owns the device, or

	group {group}

to set the group that owns the device and adding a line such as

	devfs_system_ruleset=localrules

to /etc/rc.conf.  For example, an /etc/devfs.rules file with

	[localrules=10]
	add path 'bpf*' mode 0660 group wheel

will grant read and write permissions on all BPF devices to all users in
the "wheel" group.

Note: We *probably* don't support HP-UX any more, at least not in the
sense that you can run `configure; make` or `cmake ... ; make` and
expect everything to work out of the box. At the time of this writing
(August 2017) the most recent version of Wireshark available at the
HP-UX Porting and Archive Centre is 1.10.5 and the most recently
reported HP-UX bug (#6550) was from 2012. The Porting and Archive Centre
provides libraries required to build TShark, and while the GTK+ packages
are current (2.24.31) they are 32-bit only. Recent Qt packages are not
provided.

Contents:

1 - Building wireshark
2 - Building GTK+/GLib with HP's C compiler
3 - nettl support
4 - libpcap on HP-UX
5 - HP-UX patches to fix packet capture problems

1 - Building wireshark

The HP-UX Porting and Archive Centre, at

	http://hpux.connect.org.uk/

(with mirrors in various countries, listed on the Centre's home page;
you may want to choose a mirror closer to you) has ported versions, in
both source and binary form, for Wireshark, as well as for the libpcap,
GLib, GTK+, and zlib libraries that it uses.

The changes they've made appear largely to be compile option changes; if
you've downloaded the source to the latest version of Wireshark (the
version on the Centre's site may not necessarily be the latest version),
it should be able to compile, perhaps with those changes.

They appear to have used HP-UX's "cc" compiler, with the options "-Ae
-O"; there's a comment "Add -Dhpux_9 if building under 9.X".  It may
also build with GCC.

They currently have libpcap 0.6.2; libpcap 0.6.2, and later versions,
include changes to properly open network devices when given the name
reported by the lanscan and ifconfig commands - earlier versions didn't
do this correctly.  Therefore, we strongly suggest you use libpcap 0.6.2
or later, not libpcap 0.5.2.

2 - Building GTK+/GLib with HP's C compiler

By default, HP's C compiler doesn't support "long long int" to provide
64-bit integral data types on 32-bit platforms; the "-Ae" flag must be
supplied to enable extensions such as that.

Wireshark's "configure" script automatically includes that flag if it
detects that the native compiler is being used on HP-UX; however, the
configure scripts for GTK+ and GLib don't do so, which means that 64-bit
integer support won't be enabled.

This may prevent some parts of Wireshark from compiling; in order to get
64-bit integer support in GTK+/GLib, edit all the Makefiles for GTK+ and
GLib, as generated by the GTK+ and GLib "configure" scripts, to add
"-Ae" to all "CFLAGS = " definitions found in those Makefiles.  (If a
Makefile lacks a "CFLAGS = " definition, there's no need to add a
definition that includes "-Ae".)

3 - nettl support

nettl is used on HP-UX to trace various streams based subsystems.  Wireshark
can read nettl files containing raw IP frames (NS_LS_IP, NS_LS_TCP,
NS_LS_UDP, NS_LS_ICMP subsystems), all ethernet/tokenring/fddi driver
level frames (such as BTLAN, BASE100, GELAN, IGELAN subsystems) and LAPB
frames (SX25L2 subsystem).  Use "ioscan -kfClan" to see the driver
names and compare that to /etc/nettlgen.conf to find the nettl subsystem
name for your particular release.

It has been tested with files generated on HP-UX 9.04, 10.20, and 11.x.

Use the following commands to generate a trace (cf. nettl(1M)):

# IP capture:
nettl -tn pduin pduout -e NS_LS_IP -f tracefile
# Driver level capture.  Replace btlan with the name of your interface:
nettl -tn pduin pduout -e btlan -f tracefile
# X25 capture. You must specify an interface :
nettl -tn pduin pduout -e SX25l2 -d /dev/x25_0 -f tracefile
# stop capture. subsystem is NS_LS_IP, btlan, SX25L2 :
nettl -tf -e subsystem

You may have to use "-tn 0x30000000" instead of "-tn pduin pduout"
on old versions of 10.20 and 9.04.

4 - libpcap on HP-UX

If you want to use Wireshark to capture packets, you will have to install
libpcap; binary distributions are, as noted above, available from the
Software Porting And Archive Centre for HP-UX, as well as source code.

Versions of libpcap prior to 0.6 didn't handle HP-UX as well as 0.6 and
later versions do.  You should install the latest version.

The source code is also available from the official home of libpcap and
tcpdump, at

	https://www.tcpdump.org/

if you want a version later than the version available from the Software
Porting And Archive Centre; however, the versions available from
tcpdump.org might not, for example, include support for building libpcap
as a shared library.

5 - HP-UX patches to fix packet capture problems

Note that packet-capture programs such as Wireshark/TShark or tcpdump
may, on HP-UX, not be able to see packets sent from the machine on which
they're running.  Make sure you have a recent "LAN Cummulative/DLPI" patch
installed.

Some articles on groups.google.com discussing this are:

	https://groups.google.com/forum/#!msg/comp.sys.hp.hpux/HRiDV1oLps0/fPz4gsZNvmMJ

which says:

  Newsgroups: comp.sys.hp.hpux
  Subject:  Re: Did someone made tcpdump working on 10.20 ?
  Date: 12/08/1999
  From: Lutz Jaenicke <jaenicke@emserv1.ee.TU-Berlin.DE>

  In article <82ks5i$5vc$1@news1.dti.ne.jp>, mtsat <mtsat@iris.dti.ne.jp>
  wrote:
   >Hello,
   >
   >I downloaded and compiled tcpdump3.4 a couple of week ago. I tried to use
   >it, but I can only see incoming data, never outgoing.
   >Someone (raj) explained me that a patch was missing, and that this patch
   >must me "patched" (poked) in order to see outbound data in promiscuous mode.
   >Many things to do .... So the question is : did someone has already this
   >"ready to use" PHNE_**** patch ?

   Two things:
   1. You do need a late "LAN products cumulative patch" (e.g.  PHNE_18173
  for   s700/10.20).
   2. You must use
echo 'lanc_outbound_promisc_flag/W1' | /usr/bin/adb -w /stand/vmunix /dev/kmem
     You can insert this e.g. into /sbin/init.d/lan

   Best regards,
   Lutz

and

	https://groups.google.com/d/msg/comp.sys.hp.hpux/p_Z7GlZ_A7Q/RW2jDa6gB7kJ

which says:

  Newsgroups: comp.sys.hp.hpux
  Subject: Re: tcpdump only shows incoming packets
  Date: 02/15/2000
  From: Rick Jones <foo@bar.baz.invalid>

  Harald Skotnes <harald@cc.uit.no> wrote:
  > I am running HPUX 11.0 on a C200 hanging on a 100Mb switch. I have
  > compiled libpcap-0.4 an tcpdump-3.4 and it seems to work. But at a
  > closer look I only get to see the incoming packets not the
  > outgoing. I have tried tcpflow-0.12 which also uses libpcap and the
  > same thing happens.  Could someone please give me a hint on how to
  > get this right?

  Search/Read the archives ?-)

  What you are seeing is expected, un-patched, behaviour for an HP-UX
  system.  On 11.00, you need to install the latest lancommon/DLPI
  patches, and then the latest driver patch for the interface(s) in use.
  At that point, a miracle happens and you should start seeing outbound
  traffic.

[That article also mentions the patch that appears below.]

and

	https://groups.google.com/d/msg/comp.sys.hp.hpux/p_Z7GlZ_A7Q/Q3Jg6069KB0J

which says:

  Newsgroups: comp.sys.hp.hpux
  Subject: Re: tcpdump only shows incoming packets
  Date: 02/16/2000
  From: Harald Skotnes <harald@cc.uit.no>

  Rick Jones wrote:

	...

  > What you are seeing is expected, un-patched, behaviour for an HP-UX
  > system. On 11.00, you need to install the latest lancommon/DLPI
  > patches, and then the latest driver patch for the interface(s) in
  > use. At that point, a miracle happens and you should start seeing
  > outbound traffic.

  Thanks a lot.  I have this problem on several machines running HPUX
  10.20 and 11.00.  The machines where patched up before y2k so did not
  know what to think.  Anyway I have now installed PHNE_19766,
  PHNE_19826, PHNE_20008, PHNE_20735 on the C200 and now I can see the
  outbound traffic too.  Thanks again.

(although those patches may not be the ones to install - there may be
later patches).

And another message to tcpdump-workers@tcpdump.org, from Rick Jones:

  Date: Mon, 29 Apr 2002 15:59:55 -0700
  From: Rick Jones
  To: tcpdump-workers@tcpdump.org
  Subject: Re: [tcpdump-workers] I Can't Capture the Outbound Traffic

	...

  http://itrc.hp.com/ would be one place to start in a search for the most
  up-to-date patches for DLPI and the lan driver(s) used on your system (I
  cannot guess because 9000/800 is too generic - one hs to use the "model"
  command these days and/or an ioscan command (see manpage) to guess what
  the drivers (btlan[3456], gelan, etc) might be involved in addition to
  DLPI.

  Another option is to upgrade to 11i as outbound promiscuous mode support
  is there in the base OS, no patches required.

Another posting:

	https://groups.google.com/d/msg/comp.sys.hp.hpux/5x0bKAUDCeM/Xufd5Xx05iUJ

indicates that you need to install the optional STREAMS product to do
captures on HP-UX 9.x:

  Newsgroups: comp.sys.hp.hpux
  Subject:  Re: tcpdump HP/UX 9.x
  Date: 03/22/1999
  From: Rick Jones <foo@bar.baz>

  Dave Barr (barr@cis.ohio-state.edu) wrote:
  : Has anyone ported tcpdump (or something similar) to HP/UX 9.x?

  I'm reasonably confident that any port of tcpdump to 9.X would require
  the (then optional) STREAMS product.  This would bring DLPI, which is
  what one uses to access interfaces in promiscuous mode.

  I'm not sure that HP even sells the 9.X STREAMS product any longer,
  since HP-UX 9.X is off the pricelist (well, maybe 9.10 for the old 68K
  devices).

  Your best bet is to be up on 10.20 or better if that is at all
  possible.  If your hardware is supported by it, I'd go with HP-UX 11.
  If you want to see the system's own outbound traffic, you'll never get
  that functionality on 9.X, but it might happen at some point for 10.20
  and 11.X.

  rick jones

(as per other messages cited here, the ability to see the system's own
outbound traffic did happen).

Rick Jones reports that HP-UX 11i needs no patches for outbound
promiscuous mode support.

An additional note, from Jost Martin, for HP-UX 10.20:

	Q: How do I get wireshark on HPUX to capture the _outgoing_ packets
	   of an interface
	A: You need to get PHNE_20892,PHNE_20725 and PHCO_10947 (or
	   newer, this is as of 4.4.00) and its dependencies.  Then you can
	   enable the feature as described below:

	Patch Name: PHNE_20892
	Patch Description: s700 10.20 PCI 100Base-T cumulative patch
		To trace the outbound packets, please do the following
		to turn on a global promiscuous switch before running
		the promiscuous applications like snoop or tcpdump:

		adb -w /stand/vmunix /dev/mem
		lanc_outbound_promisc_flag/W 1
		(adb will echo the result showing that the flag has
		been changed)
		$quit
	(Thanks for this part to HP-support, Ratingen)

		The attached hack does this and some security-related stuff
	(thanks to hildeb@www.stahl.bau.tu-bs.de (Ralf Hildebrandt) who
	posted the security-part some time ago)

		 <<hack_ip_stack>>

		(Don't switch IP-forwarding off, if you need it !)
		Install the hack as /sbin/init.d/hacl_ip_stack (adjust
	permissions !) and make a sequencing-symlink
	/sbin/rc2.d/S350hack_ip_stack pointing to this script.
		Now all this is done on every reboot.

According to Rick Jones, the global promiscuous switch also has to be
turned on for HP-UX 11.00, but not for 11i - and, in fact, the switch
doesn't even exist on 11i.

Here's the "hack_ip_stack" script:

-----------------------------------Cut Here-------------------------------------
#!/sbin/sh
#
# nettune:  hack kernel parms for safety

OKAY=0
ERROR=-1

# /usr/contrib/bin fuer nettune auf Pfad
PATH=/sbin:/usr/sbin:/usr/bin:/usr/contrib/bin
export PATH


##########
#  main  #
##########

case $1 in
   start_msg)
      print "Tune IP-Stack for security"
      exit $OKAY
      ;;

   stop_msg)
      print "This action is not applicable"
      exit $OKAY
      ;;

   stop)
      exit $OKAY
      ;;

   start)
      ;;  # fall through

   *)
      print "USAGE: $0 {start_msg | stop_msg | start | stop}" >&2
      exit $ERROR
      ;;
   esac

###########
#  start  #
###########

#
# tcp-Sequence-Numbers nicht mehr inkrementieren sondern random
# Syn-Flood-Protection an
# ip_forwarding aus
# Source-Routing aus
# Ausgehende Packets an ethereal/tcpdump etc.

/usr/contrib/bin/nettune -s tcp_random_seq 2 || exit $ERROR
/usr/contrib/bin/nettune -s hp_syn_protect 1 || exit $ERROR
/usr/contrib/bin/nettune -s ip_forwarding 0 || exit $ERROR
echo 'ip_block_source_routed/W1' | /usr/bin/adb -w /stand/vmunix /dev/kmem || exit $ERROR
echo 'lanc_outbound_promisc_flag/W 1' | adb -w /stand/vmunix /dev/mem  || exit $ERROR

exit $OKAY
-----------------------------------Cut Here-------------------------------------

In order to capture packets (with Wireshark/TShark, tcpdump, or any
other libpcap-based packet capture program) on a Linux system, the
"packet" protocol must be supported by your kernel.  If it is not, you
may get error messages such as

	modprobe: can't locate module net-pf-17

in "/var/adm/messages", or may get messages such as

	socket: Address family not supported by protocol

from applications using libpcap.

Most recent Linux distributions will have this configured in by default.
If it is not configured in with the default kernel, and if it is not a
module loaded by default, you must configure the kernel with the
CONFIG_PACKET option for this protocol; the following note is from the
Linux "Configure.help" file for the 2.0[.x] kernel:

	Packet socket
	CONFIG_PACKET
	  The Packet protocol is used by applications which communicate
	  directly with network devices without an intermediate network
	  protocol implemented in the kernel, e.g. tcpdump. If you want them
	  to work, choose Y.

	  This driver is also available as a module called af_packet.o ( =
	  code which can be inserted in and removed from the running kernel
	  whenever you want). If you want to compile it as a module, say M
	  here and read Documentation/modules.txt; if you use modprobe or
	  kmod, you may also want to add "alias net-pf-17 af_packet" to
	  /etc/modules.conf.

and the note for the 2.2[.x] kernel says:

	Packet socket
	CONFIG_PACKET
	  The Packet protocol is used by applications which communicate
	  directly with network devices without an intermediate network
	  protocol implemented in the kernel, e.g. tcpdump. If you want them
	  to work, choose Y. This driver is also available as a module called
	  af_packet.o ( = code which can be inserted in and removed from the
	  running kernel whenever you want). If you want to compile it as a
	  module, say M here and read Documentation/modules.txt.  You will
	  need to add 'alias net-pf-17 af_packet' to your /etc/conf.modules
	  file for the module version to function automatically.  If unsure,
	  say Y.

In addition, there is an option that, in 2.2 and later kernels, will
allow packet capture filters specified to programs such as tcpdump to be
executed in the kernel, so that packets that don't pass the filter won't
be copied from the kernel to the program, rather than having all packets
copied to the program and libpcap doing the filtering in user mode.

Copying packets from the kernel to the program consumes a significant
amount of CPU, so filtering in the kernel can reduce the overhead of
capturing packets if a filter has been specified that discards a
significant number of packets.  (If no filter is specified, it makes no
difference whether the filtering isn't performed in the kernel or isn't
performed in user mode. :-))

Most recent Linux distributions will have this configured in by default.
If it is not configured in with the default kernel, you must configure
the kernel with the CONFIG_FILTER option; the "Configure.help" file
says:

	Socket filtering
	CONFIG_FILTER
	  The Linux Socket Filter is derived from the Berkeley Packet Filter.
	  If you say Y here, user-space programs can attach a filter to any
	  socket and thereby tell the kernel that it should allow or disallow
	  certain types of data to get through the socket. Linux Socket
	  Filtering works on all socket types except TCP for now. See the text
	  file linux/Documentation/networking/filter.txt for more information.
	  If unsure, say N.

An additional problem, on Linux, with older versions of libpcap, is that
capture filters do not work when snooping loopback devices; if you're
capturing on a Linux loopback device, do not use a capture filter, as it
will probably reject most if not all packets, including the packets it's
intended to accept - instead, capture all packets and use a display
filter to select the packets you want to see.  Most recent Linux
distribution releases will not have this problem.

In addition, older versions of libpcap will, on Linux systems with a
2.0[.x] kernel, or if built for systems with a 2.0[.x] kernel, not turn
promiscuous mode off on a network device until the program using
promiscuous mode exits, so if you start a capture with Wireshark on some
Linux distributions, the network interface will be put in promiscuous
mode and will remain in promiscuous mode until Wireshark exits.  There
might be additional libpcap bugs that cause it not to be turned off even
when Wireshark exits; if your network is busy, this could cause the Linux
networking stack to do a lot more work discarding packets not intended
for the machine, so you may want to check, after running Wireshark,
whether any network interfaces are in promiscuous mode (the output of
"ifconfig -a" will say something such as

eth0      Link encap:Ethernet  HWaddr 00:00:66:66:66:66
          inet addr:66.66.66.66  Bcast:66.66.66.255  Mask:255.255.255.0
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:6493 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3380 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          Interrupt:18 Base address:0xfc80

with "PROMISC" indicating that the interface is in promiscuous mode),
and, if any interfaces are in promiscuous mode and no capture is being
done on that interface, turn promiscuous mode off by hand with

	ifconfig <ifname> -promisc

where "<ifname>" is the name of the interface.

Newer versions of libpcap shouldn't have this problem, even on 2.0[.x]
kernels; no version of libpcap should have that problem on systems with
2.2 or later kernels.

This file tries to help building Wireshark for macOS (The Operating
System Formerly Known As Mac OS X And Then OS X) (Wireshark does not
work on the classic Mac OS).

You must have the developer tools (called Xcode) installed.  For
versions of macOS up to and including Snow Leopard, Xcode 3 should be
available on the install DVD; Xcode 4 is available for download from
developer.apple.com and, for Lion and later releases, from the Mac App
Store.  See

	https://guide.macports.org/#installing.xcode

for details.  For Xcode 4, you will need to install the command-line
tools; select Preferences from the Xcode menu, select Downloads in the
Preferences window, and install Command Line Tools.

You must also have GLib and, if you want to build Wireshark as well as
TShark, you must have also Qt installed.  You can download precompiled
Qt packages and source code from

	https://www.qt.io/download

or use the tools/macos-setup.sh script described below.

You should have CMake installed; you can download binary distributions
for macOS from

	https://cmake.org/download/

The tools/macos-setup.sh script can be used to download, patch as
necessary, build as necessary, and install those libraries and the
libraries on which they depend, along with tools such as CMake; it will,
by default, also install other libraries that can be used by Wireshark
and TShark.  The versions of libraries and tools to download are
specified by variables set early in the script; you can comment out the
settings of optional libraries if you don't want them downloaded and
installed.  Before running the tools/macos-setup.sh script, and before
attempting to build Wireshark, make sure your PKG_CONFIG_PATH
environment variable's setting includes /usr/local/lib/pkgconfig.

The tools/macos-setup.sh script must be run from the top-level source
directory.

After you have installed those libraries:

 1. If you have installed Qt into some non-standard place, as is
	distinctly possible with the build included with
	macos-setup.sh, you must inform cmake by either including its
	"bin" directory as part of the PATH environment variable or
	setting CMAKE_PREFIX_PATH to the directory above Qt's "lib"
	directory.  For Qt 5.8 installed into one's home directory,
	for instance:

	% export CMAKE_PREFIX_PATH=~/Qt5.8.0/5.8/clang_64

	This step is unnecessary if you've used a recent version of
	Homebrew, as the CMake build scripts will find Qt.

 2. Make a directory in which Wireshark is to be built, separate
	from the top-level source directory for Wireshark - it can be a
	subdirectory of that top-level source directory;

 3. cd to that directory, and run CMake, with an argument that is a
	path to the top-level source directory;

 4. When CMake finishes, run make to build Wireshark.

For example, to build Wireshark in a subdirectory of the top-level
source directory, named "build", do, from the top-level source
directory;

	mkdir build
	cd build
	cmake ..
	make

It is also possible to use the Xcode IDE to build and debug Wireshark
using cmake's Xcode generator. Create a separate build directory, as
described above and run cmake with the "-G Xcode" argument to create
a Xcode project file in the current directory.

	cmake -G Xcode ..

 1. Double click Wireshark.xcodeproj

 2. Choose to create schemes manually

 3. Create a scheme for the ALL_BUILD target

 4. Edit the scheme, go to the run configuration and select Wireshark.app
  as executable

If you upgrade the major release of macOS on which you are building
Wireshark, we advise that, before you do any builds after the upgrade,
you remove the build directory and all its subdiretories, and repeat the
above process, re-running CMake and rebuilding from scratch.

On Snow Leopard (10.6) and later releases, if you are building on a
machine with a 64-bit processor (with the exception of the early Intel
Core Duo and Intel Core Solo machines, all Apple machines with Intel
processors have 64-bit processors), the C/C++/Objective-C compiler will
build 64-bit by default.

This means that you will, by default, get a 64-bit version of Wireshark.

One consequence of this is that, if you built and installed any required
or optional libraries for Wireshark on an earlier release of macOS, those
are probably 32-bit versions of the libraries, and you will need to
un-install them and rebuild them on your current version of macOS, to get
64-bit versions.

Some required and optional libraries require special attention if you
install them by building from source code on Snow Leopard and later
releases; the tools/macos-setup.sh script will handle that for you.

GLib - the GLib configuration script determines whether the system's
libiconv is GNU iconv or not by checking whether it has libiconv_open(),
and the compile will fail if that test doesn't correctly indicate
whether libiconv is GNU iconv.  In macOS, libiconv is GNU iconv, but the
64-bit version doesn't have libiconv_open(); a workaround for this is to
replace all occurrences of "libiconv_open" with "iconv_open" in the
configure script before running the script.  The tools/macos-setup.sh
setup script will patch GLib to work around this.

libgcrypt - the libgcrypt configuration script attempts to determine
which flavor of assembler-language routines to use based on the platform
type determined by standard autoconf code.  That code uses uname to
determine the processor type; however, in macOS, uname always reports
"i386" as the processor type on Intel machines, even Intel machines with
64-bit processors, so it will attempt to assemble the 32-bit x86
assembler-language routines, which will fail.  The workaround for this
is to run the configure script with the --disable-asm argument, so that
the assembler-language routines are not used.  The tools/macos-setup.sh
will configure libgcrypt with that option.

General Information
-------------------

Wireshark is a network traffic analyzer, or "sniffer", for Linux, macOS,
\*BSD and other Unix and Unix-like operating systems and for Windows.
It uses Qt, a graphical user interface library, and libpcap and npcap as
packet capture and filtering libraries.

The Wireshark distribution also comes with TShark, which is a
line-oriented sniffer (similar to Sun's snoop or tcpdump) that uses the
same dissection, capture-file reading and writing, and packet filtering
code as Wireshark, and with editcap, which is a program to read capture
files and write the packets from that capture file, possibly in a
different capture file format, and with some packets possibly removed
from the capture.

The official home of Wireshark is https://www.wireshark.org.

The latest distribution can be found in the subdirectory https://www.wireshark.org/download


Installation
------------

The Wireshark project builds and tests regularly on the following platforms:

  - Linux (Ubuntu)
  - Microsoft Windows
  - macOS / {Mac} OS X

Official installation packages are available for Microsoft Windows and
macOS.

It is available as either a standard or add-on package for many popular
operating systems and Linux distributions including Debian, Ubuntu, Fedora,
CentOS, RHEL, Arch, Gentoo, openSUSE, FreeBSD, DragonFly BSD, NetBSD, and
OpenBSD.

Additionally it is available through many third-party packaging systems
such as pkgsrc, OpenCSW, Homebrew, and MacPorts.

It should run on other Unix-ish systems without too much trouble.

In some cases the current version of Wireshark might not support your
operating system. This is the case for Windows XP, which is supported by
Wireshark 1.10 and earlier. In other cases the standard package for
Wireshark might simply be old. This is the case for Solaris and HP-UX.

Both Perl and Python 3 are needed, the former for building the man
pages.

You must therefore install Perl, Python, GNU "make", and "flex" (vanilla
"lex" won't work) on systems that lack them.

Full installation instructions can be found in the INSTALL file and in the
Developer's Guide at https://www.wireshark.org/docs/wsdg_html_chunked/

See also the appropriate README._OS_ files for OS-specific installation
instructions.

Usage
-----

In order to capture packets from the network, you need to make the
dumpcap program set-UID to root or you need to have access to the
appropriate entry under `/dev` if your system is so inclined (BSD-derived
systems, and systems such as Solaris and HP-UX that support DLPI,
typically fall into this category).  Although it might be tempting to
make the Wireshark and TShark executables setuid root, or to run them as
root please don't.  The capture process has been isolated in dumpcap;
this simple program is less likely to contain security holes and is thus
safer to run as root.

Please consult the man page for a description of each command-line
option and interface feature.


Multiple File Types
-------------------

Wireshark can read packets from a number of different file types.  See
the Wireshark man page or the Wireshark User's Guide for a list of
supported file formats.

Wireshark can transparently read compressed versions of any of those files if
the required compression library was available when Wireshark was compiled.
Currently supported compression formats are:

- GZIP
- ZSTD
- LZ4

You can disable zlib support by running `cmake -DENABLE_ZLIB=OFF`.

Although Wireshark can read AIX iptrace files, the documentation on
AIX's iptrace packet-trace command is sparse.  The `iptrace` command
starts a daemon which you must kill in order to stop the trace. Through
experimentation it appears that sending a HUP signal to that iptrace
daemon causes a graceful shutdown and a complete packet is written
to the trace file. If a partial packet is saved at the end, Wireshark
will complain when reading that file, but you will be able to read all
other packets.  If this occurs, please let the Wireshark developers know
at wireshark-dev@wireshark.org; be sure to send us a copy of that trace
file if it's small and contains non-sensitive data.

Support for Lucent/Ascend products is limited to the debug trace output
generated by the MAX and Pipline series of products.  Wireshark can read
the output of the `wandsession`, `wandisplay`, `wannext`, and `wdd`
commands.

Wireshark can also read dump trace output from the Toshiba "Compact Router"
line of ISDN routers (TR-600 and TR-650). You can telnet to the router
and start a dump session with `snoop dump`.

CoSine L2 debug output can also be read by Wireshark. To get the L2
debug output first enter the diags mode and then use
`create-pkt-log-profile` and `apply-pkt-lozg-profile` commands under
layer-2 category. For more detail how to use these commands, you
should examine the help command by `layer-2 create ?` or `layer-2 apply ?`.

To use the Lucent/Ascend, Toshiba and CoSine traces with Wireshark, you must
capture the trace output to a file on disk.  The trace is happening inside
the router and the router has no way of saving the trace to a file for you.
An easy way of doing this under Unix is to run `telnet <ascend> | tee <outfile>`.
Or, if your system has the "script" command installed, you can save
a shell session, including telnet, to a file. For example to log to a file
named tracefile.out:

~~~
$ script tracefile.out
Script started on <date/time>
$ telnet router
..... do your trace, then exit from the router's telnet session.
$ exit
Script done on <date/time>
~~~


Name Resolution
---------------

Wireshark will attempt to use reverse name resolution capabilities
when decoding IPv4 and IPv6 packets.

If you want to turn off name resolution while using Wireshark, start
Wireshark with the `-n` option to turn off all name resolution (including
resolution of MAC addresses and TCP/UDP/SMTP port numbers to names) or
with the `-N mt` option to turn off name resolution for all
network-layer addresses (IPv4, IPv6, IPX).

You can make that the default setting by opening the Preferences dialog
using the Preferences item in the Edit menu, selecting "Name resolution",
turning off the appropriate name resolution options, and clicking "OK".


SNMP
----

Wireshark can do some basic decoding of SNMP packets; it can also use
the libsmi library to do more sophisticated decoding by reading MIB
files and using the information in those files to display OIDs and
variable binding values in a friendlier fashion.  CMake  will automatically
determine whether you have the libsmi library on your system.  If you
have the libsmi library but _do not_ want Wireshark to use it, you can run
cmake with the `-DENABLE_SMI=OFF` option.

How to Report a Bug
-------------------

Wireshark is under constant development, so it is possible that you will
encounter a bug while using it. Please report bugs at https://gitlab.com/wireshark/wireshark/-/issues.
Be sure you enter into the bug:

1. The complete build information from the "About Wireshark"
   item in the Help menu or the output of `wireshark -v` for
   Wireshark bugs and the output of `tshark -v` for TShark bugs;

2. If the bug happened on Linux, the Linux distribution you were
   using, and the version of that distribution;

3. The command you used to invoke Wireshark, if you ran
   Wireshark from the command line, or TShark, if you ran
   TShark, and the sequence of operations you performed that
   caused the bug to appear.

If the bug is produced by a particular trace file, please be sure to
attach to the bug a trace file along with your bug description.  If the
trace file contains sensitive information (e.g., passwords), then please
do not send it.

If Wireshark died on you with a 'segmentation violation', 'bus error',
'abort', or other error that produces a UNIX core dump file, you can
help the developers a lot if you have a debugger installed.  A stack
trace can be obtained by using your debugger ('gdb' in this example),
the wireshark binary, and the resulting core file.  Here's an example of
how to use the gdb command 'backtrace' to do so.

~~~
$ gdb wireshark core
(gdb) backtrace
..... prints the stack trace
(gdb) quit
$
~~~

The core dump file may be named "wireshark.core" rather than "core" on
some platforms (e.g., BSD systems).  If you got a core dump with
TShark rather than Wireshark, use "tshark" as the first argument to
the debugger; the core dump may be named "tshark.core".

Disclaimer
----------

There is no warranty, expressed or implied, associated with this product.
Use at your own risk.


Gerald Combs <gerald@wireshark.org>

Gilbert Ramirez <gram@alumni.rice.edu>

Guy Harris <gharris@sonic.net>

This document contains instructions to build Wireshark natively on Windows
using GCC and MinGW-w64 with the MSYS2 distribution.

Steps to setup the build environment:

1. Download and install MSYS2 from https://www.msys2.org.

2. Open the MSYS2 MSYS shell.

3. Update with "pacman -Syu" as many times as necessary. You may also wish
   to install base-devel at this point: pacman -S base-devel. Anytime you
   want to run pacman it's recommended to do so from the MSYS shell.

4. Install pactoys for convenience:

     $ pacman -S pactoys

5. Install the toolchain:

     $ pacboy -S toolchain:x cmake:x ninja:x ccache:x

From this point on it's a typical ninja build:

1. Open the MSYS2 MINGW64 shell.

2. Create the build directory. This example will assume the build directory
   is under the source directory:

     $ cd $srcdir && mkdir build && cd build

3. Run cmake:

     $ cmake -DENABLE_CCACHE=Yes -DDISABLE_WERROR=Yes ..

4. Instal missing dependencies using pacman (there are a few gaps) and
   re-run cmake, e.g.:

     $ pacboy -S glib2:x libpcap:x libgcrypt:x gnutls:x qt5:x \
     asciidoctor:x libssh:x libmaxminddb:x snappy:x spandsp:x \
     libilbc:x doxygen:x winsparkle:x opus:x

5. Build by running "ninja" in the build directory:

     $ ninja

There isn't a native git package provided with MSYS2 so it's recommended that
you continue using the Git-For-Windows installer (or see [1]).

Currently the Wireshark MinGW-w64 build using MSYS2 has the following
limitations:

* The ETW extcap (etwdump) does not build.

* Some optional dependencies are not available in the official MSYS2
  repositories. These are:
    * AirPcap
    * libsmi
    * Kerberos
    * Lua-unicode (Lua 5.1 is available and can be used instead)
    * SBC codec
    * BCG729 codec

* There is no Wireshark binary package available. More work is
  needed to implement this. To be decided if it will use NSIS or something
  else.

* Many compiler warnings to be fixed.

References:

[1]https://github.com/git-for-windows/git/wiki/Install-inside-MSYS2-proper

Installing Wireshark on Windows
===============================

To install Wireshark, simply download the appropriate installer program from

https://www.wireshark.org/download.html

and start it. Just keep the default settings and start Wireshark after the
installation finished (e.g. using the start menu entry).

For detailed descriptions on how to install and use Wireshark and the
related command line tools, see the Wireshark User's Guide at:

https://www.wireshark.org/docs/


Compiling the Wireshark distribution from source
================================================

If you want to develop Wireshark code yourself, you can find
comprehensive information in the Developer's Guide at:

https://www.wireshark.org/docs/