Use expr instead of bashisms.

Reviewed-By: Guy Harris <guy@alum.mit.edu>
Get rid of extra blank after unknown options.

Reviewed-By: Guy Harris <guy@alum.mit.edu>
Print a space after the options if there are any options.
TIPC support.

Reviewed-and-much-modified-by: Guy Harris <guy@alum.mit.edu>
Print only one line in non-verbose mode.

Also, don't print extra blank lines in verbose mode.
Put the addresses early in the message format, and handle short messages.

Putting the addresses after "TIPC vX.Y" matches other protocols, such as
IPv4/IPv6.

Not all messages have full headers.

Also, constify some parameters and variables.
Add DLT_PFSYNC support.

From FreeBSD PR bin/124825: tcpdump(8) does not support pfsync(4) data,
which in turn was ported over from OpenBSD.  We already have CARP
support, so we did not port that part over.
Back out DLT_PFSYNC support.

Unfortunately, the DLT_PFSYNC support depends on header files included
from the pfctl command's source tree, and trying to arrange to find that
would be too much trouble.
Fix printing of BGP optional headers.

Anonymously contributed patch; tested with Cisco and Arista routers by
the patch contributor.
Ask for more information if we don't find pcap_loop.

I give up.

People keep reporting that the configure process for tcpdump fails to
find pcap_loop, and the config.log file they send us says there's no
pcap_parse in libpcap, which suggests that something went wrong in the
build process for libpcap; perhaps they don't have Bison and the
configure script got confused and failed to cause the parser to be named
"pcap_parse", or something such as that, or perhaps Bison was recently
"improved" in a fashion that breaks that, but I've never been able to
reproduce this on any of the Linux distribution installations to which
*I* have access.

I therefore ask them to send the config.log output and make output for
libpcap; *not one of the reporters of this problem* has bothered to send
that information, so we're stuck.  Perhaps they don't care enough (in
which case, why did they bother asking us about it?), or perhaps they're
annoyed that we asked them a further question rather than Just Fixing
The Problem(TM) (in which case, all I have to say is "welcome to the
Wonderful World Of Computer Software(TM) - get used to it").

So let's just ask for all that information.  (I would not be surprised
if this doesn't suffice and that they *still* just send us the tcpdump
config.log output, but at least I'll be able to tell them that they
should have Read The Fine Error Message(TM).)
Fix typo, so setting CPPFLAGS in the environment works correctly.

Based-On-Patch-From: Simon Ruderich <simon@ruderich.org>
Ask for the libpcap Makefile while we're at it.

...so that we can see what's being used to turn grammar.y into
grammar.c.

While we're at it, say "config.log file from the libpcap source
directory", in the hopes of making it more likely that we'll get it in
addition to the tcpdump config.log.
Fix the other typo, so setting CPPFLAGS in the environment works correctly.

Based-On-Patch-From: Simon Ruderich <simon@ruderich.org>
Discuss buffering when describing the -w flag.

Mention that the output of tcpdump -w is buffered, and note that this
means packets won't necessarily show up in the output as soon as they're
received, so programs reading that output won't see them immediately,
and note that the -U flag forces "packet buffering" so that a reader
will see the packets as soon as they're received.
Give more information on -l, and note that -U works without -w.

Note that -l, on Windows (i.e., in WinDump), is unbuffered, not
line-buffered, and describe -U as an alternative (that doesn't have that
problem on Windows).

Note that -U does packet-buffering without -w.

Fix up the formatting of the example command lines with -l.
error in passed calculation
added icmpv6 test case
whitespace changes in print-ip.c
fixes from Jamal Hadi Salim <hadi@mojatatu.com> for forces: SPARSE data (per RFC 5810)
prep for 4.3.0 release