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.
If it's less than 60 seconds, print it as %.1fs, to be able to
accurately represent small values including the tenths-of-a-second.
Only use relts_print() when it is 60 seconds or more.
RFC 6275 7.3. New Advertisement Interval Option Format
Advertisement Interval
32-bit unsigned integer. The maximum time, in milliseconds,
between successive unsolicited Router Advertisement messages sent
by this router on this network interface.
Use EXTRACT_16BITS() rather than a hand-rolled macro to extract
big-endian 16-bit quantities from the packet.
When processing the message, check against the body length *and* the UDP
payload length, as well as against the raw frame length.
In some places, there was one too many levels of sizeof() -
sizeof(sizeof(XXX)) is sizeof(size_t), but we wanted the size of type
XXX.
Reviewed-By: Guy Harris <guy@alum.mit.edu>
CARP and VRRP both use IP protocol number 112, so there needs to be a -T
flag to specify that protocol 112 be dissected as CARP rather than VRRP.
Also update the man page.
Check to make sure we haven't run past the end of the LSA by doing
length checks - and be a bit fussier about length checks. Do more
end-of-packet checks as well.
Loop as long as the remaining option list length is not zero, even if
that means we try to process the remaining options if the remaining
length is 1, so that if the option length is bogus, we'll report it.
Check for a valid ESIS_OPTION_ES_CONF_TIME length - it's supposed to be
2.
Glibc 2.14 doesn't install the ONC RPC headers, but it installs the ONC
RPC routines, presumably for binary compatibility. Don't use
getrpcbynumber() unless we have it *and* the header file to declare it.
