RFC 1119 says
Peer Poll Interval (peer.ppoll, pkt.ppoll): This is a signed
integer indicating the minimum interval between messages
sent by the peer, in seconds as a power of two. For
instance, a alue of six indicates a minimum interval of 64
seconds.
so print both the raw value and 2^{raw value}, showing the latter.
Patch from Debian bug 686276.
Reviewed-By: Guy Harris <guy@alum.mit.edu>
Use strtol() and only treat the argument as a number if it's *all*
number, so that interface names such as 192_1_2 aren't treated as
"interface number 192".
NAME_MAX is the maximum length of a file pathname *component*; PATH_MAX
is the maximum length of a file pathname. We're dealing with pathnames,
so use PATH_MAX. (On some systems, NAME_MAX can be as low as 14,
presumably for binary compatibility with V7-era data structures
containing file names, as there are probably few if any non-historic
UN*Xes around with 14-character file name limitations.)
Boost the default PATH_MAX to 1024 while we're at it.
The LLDP printer doesn't show the packet protocol unless -v is used,
which results in pretty useless output lines where only the timestamp is
present. Make sure we include the default protocol+length output even in
default mode.
Make sure we don't run past the end of a BGP attribute or LDP TLV when
dissecting the attribute/TLV.
Make some of the code do a bit more of a "step the pointer through the
data"-style dissection; that was done while debugging the changes in
question. It also fixes up some code to not check for more data than
should actually be there.
Update references to RFC 4906 from the draft, and note that RFC 4447
replaces it.
Do *NOT* assume that "%l[doxu]x" - or "%ll[doxu]" - is the way to print
a 64-bit quantity; on UN*X, it might be a "long" or a "long long",
depending on whether you're on a 32-bit or 64-bit platform and, on
Windows with MSVC++, it's not a long (even in 64-bit mode) and doesn't
use "%ll[doxu]", either. Instead, use PRI[doxu]64; that's what C99
defines, and what we define ourselves if the C environment doesn't
define it.
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.
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.
...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.
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).)
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.
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.
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.
