The check for vsnprintf() has been in the configure script since commit
8cb054c in 2000, and the only actual use of the function was in the
"#ifndef HAVE_SNPRINTF" block in missing/snprintf.c until commit 1ed63b5
in 2019. Since then tcpdump does not require vsnprintf() in any way.
My earlier commit fbd4415 did a wrong thing because it caused a failure
to fail in "make check" on Solaris 9, whereas the right thing to do when
printf() does not work as expected would be to fail the build with a
useful error message. Implement that by testing snprintf() in Autoconf
and CMake (assume that in a given libc implementation all functions in
the printf() family have the same level of support for conversion
specifications). Return 18 tests from the conditional space back into
TESTLIST.
Note that, even if there weren't horrible consequences to either 1)
having no C++ compiler, 2) setting an instruction set bit width in
CFLAGS but not in CXXFLAGS, or 3) having C and C++ compilers with
different default instruction set bit-widths, specifying that we're
C-only avoids wasting time looking for a C++ compiler.
If we set CMAKE_C_FLAGS_INIT to "-fPIC" before setting the project, that
initializes CMAKE_C_FLAGS to "-fPIC" *before* prepending the contents of
the CFLAGS environment variable, and *before* doing any tests that
depend on linking, in the project() command, so it 1) adds -fPIC before
doing those tests, so they don't fail due to the object files being
unfit to link into an executable, and 2) adds the contents of CFLAGS to
CMAKE_C_FLAGS, so the user can set CFLAGS and have it affect the build.
This requires CMake 3.7 or later, so we set 3.7 as the minimum required
on Haiku.
This should fix some of #996, although more needs to be done.
It's specified by the C90 standard (and, as I remember, by the C89
standard, although I no longer have my paper copy); no need to worry
about ancient environments that lack it, and we have some cases where we
call it in code not protected by #ifdef HAVE_STRFTIME/#endif and haven't
seen any reports of problems.
Windows minimum required is already 3.12.
This change avoids this warning:
CMake Deprecation Warning at CMakeLists.txt:7 (cmake_minimum_required):
Compatibility with CMake < 2.8.12 will be removed from a future version of
CMake.
Update the VERSION argument <min> value or use a ...<max> suffix to tell
CMake that the project does not need compatibility with older versions.
(Same as in libpcap.)
Don't pad the pflog header with BPF_WORDALIGN(); round up to a multiple
of 4, instead, as that's what all but FreeBSD do, and FreeBSD used to do
that and should go back to doing so (kern/261566).
Don't rely on the OS's pflog include files to define direction types,
reason types, action types, or the layout of the header; instead, define
them ourselves in a header of our own, with #ifs to select the ones that
are only on some platforms. That way, it'll handle some fields and
field values (the ones common to all OSes with pflog) on all OSes, even
ones without pflog.
That also expands the set of direction, reason, and action codes to what
various *BSDs and Darwin support.
Also, handle all the different AF_INET6 values in various *BSDs and
Darwin.
We only need a C compiler, and if either
1) the C and C++ compilers don't match (e.g., a defaults-to-64-bit GCC
and a defaults-to-32-bit Oracle Studio C++)
or
2) you set CFLAGS in the environment to force a 64-bit build but don't
also set CXXFLAGS
CMake will get confused and think it's doing a 32-bit build even though
we'll be doing a 64-bit build, and all sorts of weirdness will occur.
Just say "C" in the project() command.
There are two versions of pcap-config supplied on Solaris (or, at least,
on 64-bit Solaris) - a version that has the right --libs output to find
the 32-bit libraries and a version that has the right --libs output to
find the 64-bit libraries.
Try to figure out whether we're doing a 32-bit or 64-bit build (based on
the pointer size) and, for 64-bit builds, run the 64-bit version of
pcap-config.
As it turns out, most FreeBSD/CMake tcpdump builds were emitting some
warnings. This was difficult to notice because make returned success
regardless of the warnings because the compiler never received -Werror
because there was no way to tell CMake to append any compiler flags at
the build time, but not at the buildsystem generation time. In other
words, the command "make CFLAGS=-Werror" had the same effect as just
"make".
Implement the desired behaviour with "cmake -DEXTRA_CFLAGS='xyz'" and
set the variable in build.sh when and as required. Reword the comment
for clarity and define two known exemptions.
Pull in some code from CMake 3.12.4's FindPkgConfig.cmake to arrange
that, when running pkg-config, directories from CMAKE_PREFIX_PATH are in
the PKG_CONFIG_PATH environment variable.
We do this because we want to make sure that, if CMAKE_PREFIX_PATH is
set, and it points to a directory that contains a libpcap that has a .pc
file installed, we get that .pc file, but we don't yet want to require a
minimum of CMake 3.1 or later (CMake 3.1 and later do that
automatically) because there might be some long-term support OS version
that comes with an older version of CMake.
As discussed on GitHub and on the mailing list, install tcpdump into
bindir because it can be useful to non-root users too, in ways that do
not involve doing live packet captures. Original idea by Guy Harris.
That's not the case on Windows - it doesn't support #!. Look for the
perl interpreter and, if we find it, add a rule that runs tests/TESTrun
with the interpreter.
Hopefully, that will make sure we don't optimize away anything that
will, for example, cause us not to do things differently on 32-bit x86
using the x87 instructions.
It's All Very Complicated, so mirror what print-lmp.c does - just do a
calculation based on a particular input value and print the result using
the same format print-lmp.c does, and have tests/TESTrun see what that
result is.
Just do that inside tcpdump.c, so we don't need the fptype stuff.
1) We don't need libcrypto to check for the header files, and if we say
we do, we get a lot of noise from CMake about policy CMP0075.
2) We need libcrypto, with the full path specified, for library tests;
just linking with -lcrypto might not find it, or might find another
version (thanks, Apple!).
At least as I read RFC 5996 section 3.14 and RFC 4303 section 2.4, if
the cipher has a block size of which the ciphertext's size must be a
multiple, the payload must be padded to make that happen, so the
ciphertext length must be a multiple of the block size. Instead of
allocating a buffer, copying the ciphertext to it, and padding it to the
block size, fail if its size isn't a multiple of the block size.
(Note also that the old padding code added a block's worth of padding to
the end of a ciphertext block that *was* a multiple of the cipher block
size; this might have caused problems.)
Don't use the undocumented EVP_Cipher(); the lack of documentation means
a lack of information about whatever requirements it might impose. Use
EVP_DecryptUpdate() instead.
Before calling it, use EVP_CIPHER_CTX_set_padding() to say "don't do
your own padding, this block is a multiple of the cipher block size".
Instead of using EVP_CipherInit() or EVP_CipherInit_ex(), use
EVP_DecryptInit() or EVP_DecryptInit_ex(). as we're always doing
decryption and never doing encryption - the extra parameter to
EVP_CipherInit() and EVP_CipherInit_ex() is always 0.
This may address GitHub issue #814.
It may also make it a bit easier to have the code use Common Crypto on
macOS (rather than requiring that OpenSSL be installed - macOS ships
with an OpenSSL shared library for binary compatibility with older
releases, but doesn't ship with the headers, because Apple wants you
using their crypto code) and use Cryptography API: Next Generation on
Windows (Vista/Server 2008 and later) (rather than requiring a Windows
build of OpenSSL).
(Hopefully this will all work with LibreSSL.)
- the print routines for ptp different ptp messages
- test completed for sync message, announce message, delay request message,
delay response message and follow up message.
- integration of the ptp v2 code with the tcpdump code.
Signed-off-by: Partha S. Ghosh <psglinux@gmail.com>
The only function tcpdump used in libdnet was dnet_htoa(), which tries
to translate a binary DECnet address to a nodename through a lookup in
/etc/decnet.conf. The translation is slow and has a bug, so stop using
the function and remove the dependency on libdnet.
This makes tcpdump always print DECnet addresses in numeric format, if
anybody needs the translation back they are welcome to fix libdnet or
(more realistically) add an implementation of dnet_htoa() to the tcpdump
source code and use it.
(This is a forward-port of commit 9a6eb27 from tcpdump-4.9 to master.
Sadly, together with libdnet this change removes the fine work that Guy
had done in the master branch in commits ebf3f19 and 4ef8d63 to put
libdnet usage right whilst my original "do not use libdnet" commit was
aging in the pipeline.)
