git: e6083790f217 - main - tcpdump: Update to 4.99.6
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Mon, 16 Mar 2026 02:35:52 UTC
The branch main has been updated by jrm:
URL: https://cgit.FreeBSD.org/src/commit/?id=e6083790f217ba7f89cd2957922bd45e35466359
commit e6083790f217ba7f89cd2957922bd45e35466359
Merge: 5f659f2b8533 759433479b95
Author: Joseph Mingrone <jrm@FreeBSD.org>
AuthorDate: 2026-03-16 02:22:18 +0000
Commit: Joseph Mingrone <jrm@FreeBSD.org>
CommitDate: 2026-03-16 02:22:18 +0000
tcpdump: Update to 4.99.6
Changes: https://github.com/the-tcpdump-group/tcpdump/blob/tcpdump-4.99/CHANGES
Obtained from: https://www.tcpdump.org/release/tcpdump-4.99.6.tar.xz
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D55578
Differential Revision: https://reviews.freebsd.org/D55871
contrib/tcpdump/CHANGES | 78 +++-
contrib/tcpdump/CMakeLists.txt | 186 ++++++----
contrib/tcpdump/CONTRIBUTING.md | 2 +-
contrib/tcpdump/INSTALL.md | 4 +
contrib/tcpdump/Makefile.in | 28 +-
contrib/tcpdump/README.md | 2 +-
contrib/tcpdump/VERSION | 2 +-
contrib/tcpdump/addrtostr.c | 8 +-
contrib/tcpdump/autogen.sh | 41 ++-
contrib/tcpdump/checksum.c | 24 +-
contrib/tcpdump/cmake/Modules/FindPCAP.cmake | 36 ++
contrib/tcpdump/cmakeconfig.h.in | 5 +
contrib/tcpdump/config.h.in | 11 +-
contrib/tcpdump/configure | 136 +++++--
contrib/tcpdump/configure.ac | 50 ++-
contrib/tcpdump/diag-control.h | 30 +-
contrib/tcpdump/doc/README.NetBSD.md | 22 --
contrib/tcpdump/doc/README.aix.md | 17 -
contrib/tcpdump/doc/README.haiku.md | 33 --
contrib/tcpdump/doc/README.solaris.md | 46 ---
contrib/tcpdump/extract.h | 6 +-
contrib/tcpdump/ipproto.c | 3 +-
contrib/tcpdump/ipproto.h | 2 +-
contrib/tcpdump/missing/getopt_long.h | 2 +-
contrib/tcpdump/missing/snprintf.c | 508 ---------------------------
contrib/tcpdump/netdissect-stdinc.h | 15 -
contrib/tcpdump/netdissect.c | 2 +-
contrib/tcpdump/netdissect.h | 24 +-
contrib/tcpdump/nfs.h | 2 +-
contrib/tcpdump/ntp.c | 26 +-
contrib/tcpdump/ntp.h | 2 +
contrib/tcpdump/parsenfsfh.c | 17 +-
contrib/tcpdump/print-802_11.c | 2 +-
contrib/tcpdump/print-arista.c | 19 +-
contrib/tcpdump/print-ascii.c | 20 +-
contrib/tcpdump/print-bootp.c | 117 +++---
contrib/tcpdump/print-domain.c | 10 +-
contrib/tcpdump/print-egp.c | 186 +++++-----
contrib/tcpdump/print-frag6.c | 3 +
contrib/tcpdump/print-icmp6.c | 187 +++++-----
contrib/tcpdump/print-ip.c | 22 +-
contrib/tcpdump/print-ip6.c | 8 +-
contrib/tcpdump/print-ip6opts.c | 129 +++----
contrib/tcpdump/print-isakmp.c | 8 +-
contrib/tcpdump/print-isoclns.c | 82 ++---
contrib/tcpdump/print-juniper.c | 4 +-
contrib/tcpdump/print-lspping.c | 5 +-
contrib/tcpdump/print-lwapp.c | 86 ++---
contrib/tcpdump/print-mobility.c | 138 +++-----
contrib/tcpdump/print-msdp.c | 51 ++-
contrib/tcpdump/print-ntp.c | 4 +-
contrib/tcpdump/print-otv.c | 74 ----
contrib/tcpdump/print-pflog.c | 2 +-
contrib/tcpdump/print-ppp.c | 2 -
contrib/tcpdump/print-ptp.c | 80 +++--
contrib/tcpdump/print-raw.c | 2 +-
contrib/tcpdump/print-sunrpc.c | 2 +-
contrib/tcpdump/print-tcp.c | 60 ++--
contrib/tcpdump/print-udp.c | 4 +-
contrib/tcpdump/print-zep.c | 42 +--
contrib/tcpdump/rpc_auth.h | 2 +-
contrib/tcpdump/rpc_msg.h | 2 +-
contrib/tcpdump/tcpdump.1.in | 68 +++-
contrib/tcpdump/tcpdump.c | 358 ++++++++++++++++---
contrib/tcpdump/timeval-operations.h | 2 +
contrib/tcpdump/udp.h | 4 +-
contrib/tcpdump/util-print.c | 63 ++--
usr.sbin/tcpdump/tcpdump/Makefile | 1 -
usr.sbin/tcpdump/tcpdump/config.h | 42 +--
69 files changed, 1592 insertions(+), 1669 deletions(-)
diff --cc contrib/tcpdump/CONTRIBUTING.md
index 215e4c6831c4,000000000000..fdad452b47b8
mode 100644,000000..100644
--- a/contrib/tcpdump/CONTRIBUTING.md
+++ b/contrib/tcpdump/CONTRIBUTING.md
@@@ -1,394 -1,0 +1,394 @@@
+# Some Information for Contributors
+Thank you for considering to make a contribution to tcpdump! Please use the
+guidelines below to achieve the best results and experience for everyone.
+
+## How to report bugs and other problems
+**To report a security issue (segfault, buffer overflow, infinite loop, arbitrary
+code execution etc) please send an e-mail to security@tcpdump.org, do not use
+the bug tracker!**
+
+To report a non-security problem (failure to compile, incorrect output in the
+protocol printout, missing support for a particular protocol etc) please check
+first that it reproduces with the latest stable release of tcpdump and the latest
+stable release of libpcap. If it does, please check that the problem reproduces
+with the current git master branch of tcpdump and the current git master branch of
+libpcap. If it does (and it is not a security-related problem, otherwise see
+above), please navigate to the
+[bug tracker](https://github.com/the-tcpdump-group/tcpdump/issues)
+and check if the problem has already been reported. If it has not, please open
+a new issue and provide the following details:
+
+* tcpdump and libpcap version (`tcpdump --version`)
+* operating system name and version and any other details that may be relevant
+ (`uname -a`, compiler name and version, CPU type etc.)
+* custom `configure`/`cmake` flags, if any
+* statement of the problem
+* steps to reproduce
+
+Please note that if you know exactly how to solve the problem and the solution
+would not be too intrusive, it would be best to contribute some development time
+and to open a pull request instead as discussed below.
+
+Still not sure how to do? Feel free to
+[subscribe to the mailing list](https://www.tcpdump.org/#mailing-lists)
+and ask!
+
+
+## How to add new code and to update existing code
+
+1) Check that there isn't a pull request already opened for the changes you
+ intend to make.
+
- 2) [Fork](https://help.github.com/articles/fork-a-repo/) the Tcpdump
++2) [Fork](https://help.github.com/articles/fork-a-repo/) the tcpdump
+ [repository](https://github.com/the-tcpdump-group/tcpdump).
+
+3) The easiest way to test your changes on multiple operating systems and
+ architectures is to let the upstream CI test your pull request (more on
+ this below).
+
+4) Setup your git working copy
+ ```
+ git clone https://github.com/<username>/tcpdump.git
+ cd tcpdump
+ git remote add upstream https://github.com/the-tcpdump-group/tcpdump
+ git fetch upstream
+ ```
+
+5) Do a `touch .devel` in your working directory.
+ Currently, the effect is
+ * add (via `configure`, in `Makefile`) some warnings options (`-Wall`,
+ `-Wmissing-prototypes`, `-Wstrict-prototypes`, ...) to the compiler if it
+ supports these options,
+ * have the `Makefile` support `make depend` and the `configure` script run it.
+
+6) Configure and build
+ ```
+ ./configure && make -s && make check
+ ```
+
+7) Add/update tests
+ The `tests` directory contains regression tests of the dissection of captured
+ packets. Those captured packets were saved running tcpdump with option
+ `-w sample.pcap`. Additional options, such as `-n`, are used to create relevant
+ and reproducible output; `-#` is used to indicate which particular packets
+ have output that differs. The tests are run with the `TZ` environment
+ variable set to `GMT0`, so that UTC, rather than the local time where the
+ tests are being run, is used when "local time" values are printed. The
+ actual test compares the current text output with the expected result
+ (`sample.out`) saved from a previous version.
+
+ Any new/updated fields in a dissector must be present in a `sample.pcap` file
+ and the corresponding output file.
+
+ Configuration is set in `tests/TESTLIST`.
+ Each line in this file has the following format:
+ ```
+ test-name sample.pcap sample.out tcpdump-options
+ ```
+
+ The `sample.out` file can be produced as follows:
+ ```
+ (cd tests && TZ=GMT0 ../tcpdump -# -n -r sample.pcap tcpdump-options > sample.out)
+ ```
+
+ Or, for convenience, use `./update-test.sh test-name`
+
+ It is often useful to have test outputs with different verbosity levels
+ (none, `-v`, `-vv`, `-vvv`, etc.) depending on the code.
+
+8) Test using `make check` (current build options) and `./build_matrix.sh`
+ (a multitude of build options, build systems and compilers). If you can,
+ test on more than one operating system. Don't send a pull request until
+ all tests pass.
+
+9) Try to rebase your commits to keep the history simple.
+ ```
+ git fetch upstream
+ git rebase upstream/master
+ ```
+ (If the rebase fails and you cannot resolve, issue `git rebase --abort`
+ and ask for help in the pull request comment.)
+
+10) Once 100% happy, put your work into your forked repository using `git push`.
+
+11) [Initiate and send](https://help.github.com/articles/using-pull-requests/)
+ a pull request.
+ This will trigger the upstream repository CI tests.
+
+
+## Code style and generic remarks
+1) A thorough reading of some other printers code is useful.
+
+2) To help learn how tcpdump works or to help debugging:
+ You can configure and build tcpdump with the instrumentation of functions:
+ ```
+ $ ./configure --enable-instrument-functions
+ $ make -s clean all
+ ```
+
+ This generates instrumentation calls for entry and exit to functions.
+ Just after function entry and just before function exit, these
+ profiling functions are called and print the function names with
+ indentation and call level.
+
+ If entering in a function, it prints also the calling function name with
+ file name and line number. There may be a small shift in the line number.
+
+ In some cases, with Clang 11, the file number is unknown (printed '??')
+ or the line number is unknown (printed '?'). In this case, use GCC.
+
+ If the environment variable INSTRUMENT is
+ - unset or set to an empty string, print nothing, like with no
+ instrumentation
+ - set to "all" or "a", print all the functions names
+ - set to "global" or "g", print only the global functions names
+
+ This allows to run:
+ ```
+ $ INSTRUMENT=a ./tcpdump ...
+ $ INSTRUMENT=g ./tcpdump ...
+ $ INSTRUMENT= ./tcpdump ...
+ ```
+ or
+ ```
+ $ export INSTRUMENT=global
+ $ ./tcpdump ...
+ ```
+
+ The library libbfd is used, therefore the binutils-dev package is required.
+
+3) Put the normative reference if any as comments (RFC, etc.).
+
+4) Put the format of packets/headers/options as comments if there is no
+ published normative reference.
+
+5) The printer may receive incomplete packet in the buffer, truncated at any
+ random position, for example by capturing with `-s size` option.
+ This means that an attempt to fetch packet data based on the expected
+ format of the packet may run the risk of overrunning the buffer.
+
+ Furthermore, if the packet is complete, but is not correctly formed,
+ that can also cause a printer to overrun the buffer, as it will be
+ fetching packet data based on the expected format of the packet.
+
+ Therefore, integral, IPv4 address, and octet sequence values should
+ be fetched using the `GET_*()` macros, which are defined in
+ `extract.h`.
+
+ If your code reads and decodes every byte of the protocol packet, then to
+ ensure proper and complete bounds checks it would be sufficient to read all
+ packet data using the `GET_*()` macros.
+
+ If your code uses the macros above only on some packet data, then the gaps
+ would have to be bounds-checked using the `ND_TCHECK_*()` macros:
+ ```
+ ND_TCHECK_n(p), n in { 1, 2, 3, 4, 5, 6, 7, 8, 16 }
+ ND_TCHECK_SIZE(p)
+ ND_TCHECK_LEN(p, l)
+ ```
+
+ where *p* points to the data not being decoded. For `ND_CHECK_n()`,
+ *n* is the length of the gap, in bytes. For `ND_CHECK_SIZE()`, the
+ length of the gap, in bytes, is the size of an item of the data type
+ to which *p* points. For `ND_CHECK_LEN()`, *l* is the length of the
+ gap, in bytes.
+
+ For the `GET_*()` and `ND_TCHECK_*` macros (if not already done):
+ * Assign: `ndo->ndo_protocol = "protocol";`
+ * Define: `ND_LONGJMP_FROM_TCHECK` before including `netdissect.h`
+ * Make sure that the intersection of `GET_*()` and `ND_TCHECK_*()` is minimal,
+ but at the same time their union covers all packet data in all cases.
+
+ You can test the code via:
+ ```
+ sudo ./tcpdump -s snaplen [-v][v][...] -i lo # in a terminal
+ sudo tcpreplay -i lo sample.pcap # in another terminal
+ ```
+ You should try several values for snaplen to do various truncation.
+
+* The `GET_*()` macros that fetch integral values are:
+ ```
+ GET_U_1(p)
+ GET_S_1(p)
+ GET_BE_U_n(p), n in { 2, 3, 4, 5, 6, 7, 8 }
+ GET_BE_S_n(p), n in { 2, 3, 4, 5, 6, 7, 8 }
+ GET_LE_U_n(p), n in { 2, 3, 4, 5, 6, 7, 8 }
+ GET_LE_S_n(p), n in { 2, 3, 4, 5, 6, 7, 8 }
+ ```
+
+ where *p* points to the integral value in the packet buffer. The
+ macro returns the integral value at that location.
+
+ `U` indicates that an unsigned value is fetched; `S` indicates that a
+ signed value is fetched. For multi-byte values, `BE` indicates that
+ a big-endian value ("network byte order") is fetched, and `LE`
+ indicates that a little-endian value is fetched. *n* is the length,
+ in bytes, of the multi-byte integral value to be fetched.
+
+ In addition to the bounds checking the `GET_*()` macros perform,
+ using those macros has other advantages:
+
+ * tcpdump runs on both big-endian and little-endian systems, so
+ fetches of multi-byte integral values must be done in a fashion
+ that works regardless of the byte order of the machine running
+ tcpdump. The `GET_BE_*()` macros will fetch a big-endian value and
+ return a host-byte-order value on both big-endian and little-endian
+ machines, and the `GET_LE_*()` macros will fetch a little-endian
+ value and return a host-byte-order value on both big-endian and
+ little-endian machines.
+
+ * tcpdump runs on machines that do not support unaligned access to
+ multi-byte values, and packet values are not guaranteed to be
+ aligned on the proper boundary. The `GET_BE_*()` and `GET_LE_*()`
+ macros will fetch values even if they are not aligned on the proper
+ boundary.
+
+* The `GET_*()` macros that fetch IPv4 address values are:
+ ```
+ GET_IPV4_TO_HOST_ORDER(p)
+ GET_IPV4_TO_NETWORK_ORDER(p)
+ ```
+
+ where *p* points to the address in the packet buffer.
+ `GET_IPV4_TO_HOST_ORDER()` returns the address in the byte order of
+ the host that is running tcpdump; `GET_IPV4_TO_NETWORK_ORDER()`
+ returns it in network byte order.
+
+ Like the integral `GET_*()` macros, these macros work correctly on
+ both big-endian and little-endian machines and will fetch values even
+ if they are not aligned on the proper boundary.
+
+* The `GET_*()` macro that fetches an arbitrary sequences of bytes is:
+ ```
+ GET_CPY_BYTES(dst, p, len)
+ ```
+
+ where *dst* is the destination to which the sequence of bytes should
+ be copied, *p* points to the first byte of the sequence of bytes, and
+ *len* is the number of bytes to be copied. The bytes are copied in
+ the order in which they appear in the packet.
+
+* To fetch a network address and convert it to a printable string, use
+ the following `GET_*()` macros, defined in `addrtoname.h`, to
+ perform bounds checks to make sure the entire address is within the
+ buffer and to translate the address to a string to print:
+ ```
+ GET_IPADDR_STRING(p)
+ GET_IP6ADDR_STRING(p)
+ GET_MAC48_STRING(p)
+ GET_EUI64_STRING(p)
+ GET_EUI64LE_STRING(p)
+ GET_LINKADDR_STRING(p, type, len)
+ GET_ISONSAP_STRING(nsap, nsap_length)
+ ```
+
+ `GET_IPADDR_STRING()` fetches an IPv4 address pointed to by *p* and
+ returns a string that is either a host name, if the `-n` flag wasn't
+ specified and a host name could be found for the address, or the
+ standard XXX.XXX.XXX.XXX-style representation of the address.
+
+ `GET_IP6ADDR_STRING()` fetches an IPv6 address pointed to by *p* and
+ returns a string that is either a host name, if the `-n` flag wasn't
+ specified and a host name could be found for the address, or the
+ standard XXXX::XXXX-style representation of the address.
+
+ `GET_MAC48_STRING()` fetches a 48-bit MAC address (Ethernet, 802.11,
+ etc.) pointed to by *p* and returns a string that is either a host
+ name, if the `-n` flag wasn't specified and a host name could be
+ found in the ethers file for the address, or the standard
+ XX:XX:XX:XX:XX:XX-style representation of the address.
+
+ `GET_EUI64_STRING()` fetches a 64-bit EUI pointed to by *p* and
+ returns a string that is the standard XX:XX:XX:XX:XX:XX:XX:XX-style
+ representation of the address.
+
+ `GET_EUI64LE_STRING()` fetches a 64-bit EUI, in reverse byte order,
+ pointed to by *p* and returns a string that is the standard
+ XX:XX:XX:XX:XX:XX:XX:XX-style representation of the address.
+
+ `GET_LINKADDR_STRING()` fetches an octet string, of length *length*
+ and type *type*, pointed to by *p* and returns a string whose format
+ depends on the value of *type*:
+
+ * `LINKADDR_MAC48` - if the length is 6, the string has the same
+ value as `GET_MAC48_STRING()` would return for that address,
+ otherwise, the string is a sequence of XX:XX:... values for the bytes
+ of the address;
+
+ * `LINKADDR_FRELAY` - the string is "DLCI XXX", where XXX is the
+ DLCI, if the address is a valid Q.922 header, and an error indication
+ otherwise;
+
+ * `LINKADDR_EUI64`, `LINKADDR_ATM`, `LINKADDR_OTHER` -
+ the string is a sequence of XX:XX:... values for the bytes
+ of the address.
+
+6) When defining a structure corresponding to a packet or part of a
+ packet, so that a pointer to packet data can be cast to a pointer to
+ that structure and that structure pointer used to refer to fields in
+ the packet, use the `nd_*` types for the structure members.
+
+ Those types all are aligned only on a 1-byte boundary, so a
+ compiler will not assume that the structure is aligned on a boundary
+ stricter than one byte; there is no guarantee that fields in packets
+ are aligned on any particular boundary.
+
+ This means that all padding in the structure must be explicitly
+ declared as fields in the structure.
+
+ The `nd_*` types for integral values are:
+
+ * `nd_uintN_t`, for unsigned integral values, where *N* is the number
+ of bytes in the value.
+ * `nd_intN_t`, for signed integral values, where *N* is the number
+ of bytes in the value.
+
+ The `nd_*` types for IP addresses are:
+
+ * `nd_ipv4`, for IPv4 addresses;
+ * `nd_ipv6`, for IPv6 addresses.
+
+ The `nd_*` types for link-layer addresses are:
+
+ * `nd_mac48`, for MAC-48 (Ethernet, 802.11, etc.) addresses;
+ * `nd_eui64`, for EUI-64 values.
+
+ The `nd_*` type for a byte in a sequence of bytes is `nd_byte`; an
+ *N*-byte sequence should be declared as `nd_byte[N]`.
+
+7) Do invalid packet checks in code: Think that your code can receive in input
+ not only a valid packet but any arbitrary random sequence of octets (packet
+ * built malformed originally by the sender or by a fuzz tester,
+ * became corrupted in transit or for some other reason).
+
+ Print with: `nd_print_invalid(ndo); /* to print " (invalid)" */`
+
+8) Use `struct tok` for indexed strings and print them with
+ `tok2str()` or `bittok2str()` (for flags).
+ All `struct tok` must end with `{ 0, NULL }`.
+
+9) Avoid empty lines in output of printers.
+
+10) A commit message must have:
+ ```
+ First line: Capitalized short summary in the imperative (50 chars or less)
+
+ If the commit concerns a protocol, the summary line must start with
+ "protocol: ".
+
+ Body: Detailed explanatory text, if necessary. Fold it to approximately
+ 72 characters. There must be an empty line separating the summary from
+ the body.
+ ```
+
+11) Avoid non-ASCII characters in code and commit messages.
+
+12) Use the style of the modified sources.
+
+13) Don't mix declarations and code.
+
+14) tcpdump requires a compiler that supports C99 or later, so C99
+ features may be used in code, but C11 or later features should not be
+ used.
+
+15) Avoid trailing tabs/spaces
diff --cc contrib/tcpdump/README.md
index 566b7b7a874f,000000000000..a227e126d00c
mode 100644,000000..100644
--- a/contrib/tcpdump/README.md
+++ b/contrib/tcpdump/README.md
@@@ -1,225 -1,0 +1,225 @@@
+# TCPDUMP 4.x.y by [The Tcpdump Group](https://www.tcpdump.org/)
+
+**To report a security issue please send an e-mail to security@tcpdump.org.**
+
+To report bugs and other problems, contribute patches, request a
+feature, provide generic feedback etc please see the
+[guidelines for contributing](CONTRIBUTING.md) in the tcpdump source tree root.
+
+Anonymous Git is available via
+
+ https://github.com/the-tcpdump-group/tcpdump.git
+
+This directory contains source code for tcpdump, a tool for network
+monitoring and data acquisition.
+
+Over the past few years, tcpdump has been steadily improved by the
+excellent contributions from the Internet community (just browse
+through the [change log](CHANGES)). We are grateful for all the input.
+
+### Supported platforms
+In many operating systems tcpdump is available as a native package or port,
+which simplifies installation of updates and long-term maintenance. However,
+the native packages are sometimes a few versions behind and to try a more
+recent snapshot it will take to compile tcpdump from the source code.
+
+tcpdump compiles and works on at least the following platforms:
+
+* AIX
+* DragonFly BSD
+* FreeBSD
+* Haiku
+* HP-UX 11i
+* illumos (OmniOS, OpenIndiana)
+* GNU/Linux
+* {Mac} OS X / macOS
+* NetBSD
+* OpenBSD
+* OpenWrt
+* Solaris
+* Windows (requires WinPcap or Npcap, and Visual Studio with CMake)
+
+### Dependency on libpcap
- Tcpdump uses libpcap, a system-independent interface for user-level
++tcpdump uses libpcap, a system-independent interface for user-level
+packet capture. Before building tcpdump, you must first retrieve and
+build libpcap.
+
+Once libpcap is built (either install it or make sure it's in
+`../libpcap`), you can build tcpdump using the procedure in the
+[installation notes](INSTALL.md).
+
+### Origins of tcpdump
+The program is loosely based on SMI's "etherfind" although none of the
+etherfind code remains. It was originally written by Van Jacobson as
+part of an ongoing research project to investigate and improve TCP and
+Internet gateway performance. The parts of the program originally
+taken from Sun's etherfind were later re-written by Steven McCanne of
+LBL. To insure that there would be no vestige of proprietary code in
+tcpdump, Steve wrote these pieces from the specification given by the
+manual entry, with no access to the source of tcpdump or etherfind.
+```text
+formerly from Lawrence Berkeley National Laboratory
+ Network Research Group <tcpdump@ee.lbl.gov>
+ ftp://ftp.ee.lbl.gov/old/tcpdump.tar.Z (3.4)
+```
+
+### See also
+Richard Stevens gives an excellent treatment of the Internet protocols
+in his book *"TCP/IP Illustrated, Volume 1"*. If you want to learn more
+about tcpdump and how to interpret its output, pick up this book.
+
+Another tool that tcpdump users might find useful is
+[tcpslice](https://github.com/the-tcpdump-group/tcpslice).
+It is a program that can be used to extract portions of tcpdump binary
+trace files.
+
+### The original LBL README by Steve McCanne, Craig Leres and Van Jacobson
+```
+This directory also contains some short awk programs intended as
+examples of ways to reduce tcpdump data when you're tracking
+particular network problems:
+
+send-ack.awk
+ Simplifies the tcpdump trace for an ftp (or other unidirectional
+ tcp transfer). Since we assume that one host only sends and
+ the other only acks, all address information is left off and
+ we just note if the packet is a "send" or an "ack".
+
+ There is one output line per line of the original trace.
+ Field 1 is the packet time in decimal seconds, relative
+ to the start of the conversation. Field 2 is delta-time
+ from last packet. Field 3 is packet type/direction.
+ "Send" means data going from sender to receiver, "ack"
+ means an ack going from the receiver to the sender. A
+ preceding "*" indicates that the data is a retransmission.
+ A preceding "-" indicates a hole in the sequence space
+ (i.e., missing packet(s)), a "#" means an odd-size (not max
+ seg size) packet. Field 4 has the packet flags
+ (same format as raw trace). Field 5 is the sequence
+ number (start seq. num for sender, next expected seq number
+ for acks). The number in parens following an ack is
+ the delta-time from the first send of the packet to the
+ ack. A number in parens following a send is the
+ delta-time from the first send of the packet to the
+ current send (on duplicate packets only). Duplicate
+ sends or acks have a number in square brackets showing
+ the number of duplicates so far.
+
+ Here is a short sample from near the start of an ftp:
+ 3.00 0.20 send . 512
+ 3.20 0.20 ack . 1024 (0.20)
+ 3.20 0.00 send P 1024
+ 3.40 0.20 ack . 1536 (0.20)
+ 3.80 0.40 * send . 0 (3.80) [2]
+ 3.82 0.02 * ack . 1536 (0.62) [2]
+ Three seconds into the conversation, bytes 512 through 1023
+ were sent. 200ms later they were acked. Shortly thereafter
+ bytes 1024-1535 were sent and again acked after 200ms.
+ Then, for no apparent reason, 0-511 is retransmitted, 3.8
+ seconds after its initial send (the round trip time for this
+ ftp was 1sec, +-500ms). Since the receiver is expecting
+ 1536, 1536 is re-acked when 0 arrives.
+
+packetdat.awk
+ Computes chunk summary data for an ftp (or similar
+ unidirectional tcp transfer). [A "chunk" refers to
+ a chunk of the sequence space -- essentially the packet
+ sequence number divided by the max segment size.]
+
+ A summary line is printed showing the number of chunks,
+ the number of packets it took to send that many chunks
+ (if there are no lost or duplicated packets, the number
+ of packets should equal the number of chunks) and the
+ number of acks.
+
+ Following the summary line is one line of information
+ per chunk. The line contains eight fields:
+ 1 - the chunk number
+ 2 - the start sequence number for this chunk
+ 3 - time of first send
+ 4 - time of last send
+ 5 - time of first ack
+ 6 - time of last ack
+ 7 - number of times chunk was sent
+ 8 - number of times chunk was acked
+ (all times are in decimal seconds, relative to the start
+ of the conversation.)
+
+ As an example, here is the first part of the output for
+ an ftp trace:
+
+ # 134 chunks. 536 packets sent. 508 acks.
+ 1 1 0.00 5.80 0.20 0.20 4 1
+ 2 513 0.28 6.20 0.40 0.40 4 1
+ 3 1025 1.16 6.32 1.20 1.20 4 1
+ 4 1561 1.86 15.00 2.00 2.00 6 1
+ 5 2049 2.16 15.44 2.20 2.20 5 1
+ 6 2585 2.64 16.44 2.80 2.80 5 1
+ 7 3073 3.00 16.66 3.20 3.20 4 1
+ 8 3609 3.20 17.24 3.40 5.82 4 11
+ 9 4097 6.02 6.58 6.20 6.80 2 5
+
+ This says that 134 chunks were transferred (about 70K
+ since the average packet size was 512 bytes). It took
+ 536 packets to transfer the data (i.e., on the average
+ each chunk was transmitted four times). Looking at,
+ say, chunk 4, we see it represents the 512 bytes of
+ sequence space from 1561 to 2048. It was first sent
+ 1.86 seconds into the conversation. It was last
+ sent 15 seconds into the conversation and was sent
+ a total of 6 times (i.e., it was retransmitted every
+ 2 seconds on the average). It was acked once, 140ms
+ after it first arrived.
+
+stime.awk
+atime.awk
+ Output one line per send or ack, respectively, in the form
+ <time> <seq. number>
+ where <time> is the time in seconds since the start of the
+ transfer and <seq. number> is the sequence number being sent
+ or acked. I typically plot this data looking for suspicious
+ patterns.
+
+
+The problem I was looking at was the bulk-data-transfer
+throughput of medium delay network paths (1-6 sec. round trip
+time) under typical DARPA Internet conditions. The trace of the
+ftp transfer of a large file was used as the raw data source.
+The method was:
+
+ - On a local host (but not the Sun running tcpdump), connect to
+ the remote ftp.
+
+ - On the monitor Sun, start the trace going. E.g.,
+ tcpdump host local-host and remote-host and port ftp-data >tracefile
+
+ - On local, do either a get or put of a large file (~500KB),
+ preferably to the null device (to minimize effects like
+ closing the receive window while waiting for a disk write).
+
+ - When transfer is finished, stop tcpdump. Use awk to make up
+ two files of summary data (maxsize is the maximum packet size,
+ tracedata is the file of tcpdump tracedata):
+ awk -f send-ack.awk packetsize=avgsize tracedata >sa
+ awk -f packetdat.awk packetsize=avgsize tracedata >pd
+
+ - While the summary data files are printing, take a look at
+ how the transfer behaved:
+ awk -f stime.awk tracedata | xgraph
+ (90% of what you learn seems to happen in this step).
+
+ - Do all of the above steps several times, both directions,
+ at different times of day, with different protocol
+ implementations on the other end.
+
+ - Using one of the Unix data analysis packages (in my case,
+ S and Gary Perlman's Unix|Stat), spend a few months staring
+ at the data.
+
+ - Change something in the local protocol implementation and
+ redo the steps above.
+
+ - Once a week, tell your funding agent that you're discovering
+ wonderful things and you'll write up that research report
+ "real soon now".
+```
diff --cc contrib/tcpdump/netdissect.h
index 95d17b3db8b7,faa686f15314..52dfa878c4a9
--- a/contrib/tcpdump/netdissect.h
+++ b/contrib/tcpdump/netdissect.h
@@@ -708,9 -719,6 +719,8 @@@ extern void ospf6_print(netdissect_opti
extern void ospf_print(netdissect_options *, const u_char *, u_int, const u_char *);
extern int ospf_grace_lsa_print(netdissect_options *, const u_char *, u_int);
extern int ospf_te_lsa_print(netdissect_options *, const u_char *, u_int);
- extern void otv_print(netdissect_options *, const u_char *, u_int);
+extern void pfsync_ip_print(netdissect_options *, const u_char *, u_int);
+extern void pfsync_if_print(netdissect_options *, const struct pcap_pkthdr *, const u_char *);
extern void pgm_print(netdissect_options *, const u_char *, u_int, const u_char *);
extern void pim_print(netdissect_options *, const u_char *, u_int, const u_char *);
extern void pimv1_print(netdissect_options *, const u_char *, u_int);
diff --cc usr.sbin/tcpdump/tcpdump/Makefile
index 21c5f9ac7fdf,000000000000..27270cd34dfb
mode 100644,000000..100644
--- a/usr.sbin/tcpdump/tcpdump/Makefile
+++ b/usr.sbin/tcpdump/tcpdump/Makefile
@@@ -1,226 -1,0 +1,225 @@@
+.include <src.opts.mk>
+
+TCPDUMP_DISTDIR?= ${SRCTOP}/contrib/tcpdump
+.PATH: ${TCPDUMP_DISTDIR}
+
+PROG= tcpdump
+
+SRCS= addrtoname.c \
+ addrtostr.c \
+ af.c \
+ ascii_strcasecmp.c \
+ checksum.c \
+ cpack.c \
+ fptype.c \
+ gmpls.c \
+ in_cksum.c \
+ ipproto.c \
+ l2vpn.c \
+ machdep.c \
+ netdissect.c \
+ netdissect-alloc.c \
+ nlpid.c \
+ ntp.c \
+ oui.c \
+ parsenfsfh.c \
+ print.c \
+ print-802_11.c \
+ print-802_15_4.c \
+ print-ah.c \
+ print-ahcp.c \
+ print-aodv.c \
+ print-aoe.c \
+ print-ap1394.c \
+ print-arcnet.c \
+ print-arp.c \
+ print-ascii.c \
+ print-atalk.c \
+ print-atm.c \
+ print-babel.c \
+ print-beep.c \
+ print-bfd.c \
+ print-bgp.c \
+ print-bootp.c \
+ print-bt.c \
+ print-calm-fast.c \
+ print-carp.c \
+ print-cdp.c \
+ print-cfm.c \
+ print-chdlc.c \
+ print-cip.c \
+ print-cnfp.c \
+ print-dccp.c \
+ print-decnet.c \
+ print-dhcp6.c \
+ print-domain.c \
+ print-dtp.c \
+ print-dvmrp.c \
+ print-eap.c \
+ print-egp.c \
+ print-eigrp.c \
+ print-enc.c \
+ print-esp.c \
+ print-ether.c \
+ print-fddi.c \
+ print-forces.c \
+ print-fr.c \
+ print-frag6.c \
+ print-ftp.c \
+ print-geneve.c \
+ print-geonet.c \
+ print-gre.c \
+ print-hncp.c \
+ print-hsrp.c \
+ print-http.c \
+ print-icmp.c \
+ print-icmp6.c \
+ print-igmp.c \
+ print-igrp.c \
+ print-ip.c \
+ print-ip6.c \
+ print-ip6opts.c \
+ print-ipcomp.c \
+ print-ipfc.c \
+ print-ipnet.c \
+ print-ipx.c \
+ print-isakmp.c \
+ print-isoclns.c \
+ print-juniper.c \
+ print-krb.c \
+ print-l2tp.c \
+ print-lane.c \
+ print-ldp.c \
+ print-lisp.c \
+ print-llc.c \
+ print-lldp.c \
+ print-lmp.c \
+ print-loopback.c \
+ print-lspping.c \
+ print-lwapp.c \
+ print-lwres.c \
+ print-m3ua.c \
+ print-mobile.c \
+ print-mobility.c \
+ print-mpcp.c \
+ print-mpls.c \
+ print-mptcp.c \
+ print-msdp.c \
+ print-msnlb.c \
+ print-nflog.c \
+ print-nfs.c \
+ print-nsh.c \
+ print-ntp.c \
+ print-null.c \
+ print-olsr.c \
+ print-openflow.c \
+ print-openflow-1.0.c \
+ print-ospf.c \
+ print-ospf6.c \
- print-otv.c \
+ print-pgm.c \
+ print-pim.c \
+ print-pktap.c \
+ print-ppi.c \
+ print-ppp.c \
+ print-pppoe.c \
+ print-pptp.c \
+ print-radius.c \
+ print-raw.c \
+ print-resp.c \
+ print-rip.c \
+ print-ripng.c \
+ print-rpki-rtr.c \
+ print-rsvp.c \
+ print-rt6.c \
+ print-rtsp.c \
+ print-rx.c \
+ print-sctp.c \
+ print-sflow.c \
+ print-sip.c \
+ print-sl.c \
+ print-sll.c \
+ print-slow.c \
+ print-smb.c \
+ print-smtp.c \
+ print-snmp.c \
+ print-stp.c \
+ print-sunatm.c \
+ print-sunrpc.c \
+ print-symantec.c \
+ print-syslog.c \
+ print-tcp.c \
+ print-telnet.c \
+ print-tftp.c \
+ print-timed.c \
+ print-tipc.c \
+ print-token.c \
+ print-udld.c \
+ print-udp.c \
+ print-usb.c \
+ print-vjc.c \
+ print-vqp.c \
+ print-vrrp.c \
+ print-vtp.c \
+ print-vxlan.c \
+ print-vxlan-gpe.c \
+ print-wb.c \
+ print-zephyr.c \
+ print-zeromq.c \
+ signature.c \
+ smbutil.c \
+ strtoaddr.c \
+ tcpdump.c \
+ util-print.c \
+ print-arista.c \
+ print-bcm-li.c \
+ print-brcmtag.c \
+ print-dsa.c \
+ print-ip-demux.c \
+ print-ipoib.c \
+ print-macsec.c \
+ print-openflow-1.3.c \
+ print-ptp.c \
+ print-realtek.c \
+ print-someip.c \
+ print-ssh.c \
+ print-unsupported.c \
+ print-vsock.c \
+ print-whois.c \
+ print-zep.c
+
+CLEANFILES+= ${MAN}
+
+CFLAGS+= -I${.CURDIR} -I${TCPDUMP_DISTDIR}
+CFLAGS+= -DHAVE_CONFIG_H
+CFLAGS+= -D_U_="__attribute__((unused))"
+
+.if ${MK_INET6_SUPPORT} != "no"
+CFLAGS+= -DINET6 -DHAVE_OS_IPV6_SUPPORT
+.endif
+
+LIBADD= pcap
+.if ${MK_CASPER} != "no"
+LIBADD+= casper
+LIBADD+= cap_dns
+CFLAGS+=-DHAVE_CASPER
+.endif
+.if ${MK_OPENSSL} != "no"
+LIBADD+= crypto
+CFLAGS+= -I${SYSROOT:U${DESTDIR}}/usr/include/openssl
+CFLAGS+= -DHAVE_LIBCRYPTO -DHAVE_OPENSSL_EVP_H
+CFLAGS+= -DOPENSSL_API_COMPAT=0x10100000L
+.endif
+
+.if ${MK_PF} != "no"
+SRCS+= print-pflog.c \
+ print-pfsync.c
+CFLAGS+= -DHAVE_NET_PFVAR_H -DHAVE_NET_IF_PFLOG_H
+.endif
+
+.include <bsd.prog.mk>
+
+.for mp in ${MAN}
+${mp}: ${mp}.in
+ sed -e 's/@MAN_MISC_INFO@/7/g' -e 's/@MAN_FILE_FORMATS@/5/g' \
+ ${.ALLSRC} > ${.TARGET}
+.endfor
diff --cc usr.sbin/tcpdump/tcpdump/config.h
index 5e343d5ed0c3,000000000000..1ccdbaf7647b
mode 100644,000000..100644
--- a/usr.sbin/tcpdump/tcpdump/config.h
+++ b/usr.sbin/tcpdump/tcpdump/config.h
@@@ -1,295 -1,0 +1,297 @@@
+/* This is an edited copy of the config.h generated by configure. */
+
+/* config.h. Generated from config.h.in by configure. */
+/* config.h.in. Generated from configure.ac by autoheader. */
+
++
++#ifndef TCPDUMP_CONFIG_H_
++#define TCPDUMP_CONFIG_H_
++
++
+/* Define to 1 if arpa/inet.h declares `ether_ntohost' */
+/* #undef ARPA_INET_H_DECLARES_ETHER_NTOHOST */
*** 305 LINES SKIPPED ***