Date: Mon, 16 Mar 2026 02:35:52 +0000 From: Joseph Mingrone <jrm@FreeBSD.org> To: src-committers@FreeBSD.org, dev-commits-src-all@FreeBSD.org, dev-commits-src-main@FreeBSD.org Subject: git: e6083790f217 - main - tcpdump: Update to 4.99.6 Message-ID: <69b76c88.3d38b.5176f28b@gitrepo.freebsd.org>
index | next in thread | raw e-mail
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 ***home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?69b76c88.3d38b.5176f28b>