Re: [tcpdump-workers] AC_LBL_FIXINCLUDES does not make it into configure

--- Begin Message --- On Fri, 27 Jan 2023 12:53:28 + Denis Ovsienko via tcpdump-workers wrote: [...] > I do not understand yet if AC_LBL_C_INLINE could just disappear safely > altogether instead of being replaced with AC_C_INLINE. In order to play safe, it has been re

Re: [tcpdump-workers] Z-Wave G.9959 TAP Specification version 0.94

--- Begin Message --- On Mon, 12 Dec 2022 17:06:07 -0800 Chris Brandson via tcpdump-workers wrote: > Hello Tcp Dump Workers, > > The latest 0.94 draft Z-Wave G.9959 TAP Specification is available at: > > https://gitlab.com/exegin/zwave-g9959-tap > >

Re: [tcpdump-workers] Pcap delivers packets every 200ms

--- Begin Message --- On Thu, 2 Feb 2023 15:42:55 + Paschal Chukwuebuk Amusuo via tcpdump-workers wrote: > Hi, > > Please, is there any way to force pcap to deliver packets once it > receives the packet? Currently, pcap delivers packets to my > application at intervals and it batches the

Re: [tcpdump-workers] [tcpdump] About HAVE_NO_PRINTF_Z

--- Begin Message --- On Sat, 14 Jan 2023 16:57:45 + Denis Ovsienko via tcpdump-workers wrote: [...] > So it would be practicable to restore Solaris 9 support in the > trailing edge department of tcpdump using compile-time-conditional > length modifier. If anybody volunteers to

Re: [tcpdump-workers] CPPFLAGS in C-only context

--- Begin Message --- On Mon, 23 Jan 2023 22:16:24 + Denis Ovsienko via tcpdump-workers wrote: > It looks like either in a C project context CPPFLAGS works in a > non-obvious way, or is a no-op. ...or, rather, is the C preprocessor flags variable (just as "./configure -

Re: [tcpdump-workers] AC_LBL_FIXINCLUDES does not make it into configure

--- Begin Message --- On Fri, 27 Jan 2023 01:40:48 -0800 Guy Harris wrote: > On Jan 22, 2023, at 9:59 AM, Denis Ovsienko via tcpdump-workers > wrote: > > > I have also removed AC_LBL_C_INLINE and a conditional substitute for > > Tru64 pfopen() from tcpslice. In

Re: [tcpdump-workers] AC_LBL_FIXINCLUDES does not make it into configure

--- Begin Message --- Hello all. I have removed some unused Autoconf macros here and there, including AC_LBL_CHECK_LIB in tcpslice and libpcap. This macro still remains in tcpdump, where it was a part of the initial git commit in 1999, and where it became unused in 2001 (commit d57c77a), with

[tcpdump-workers] CPPFLAGS in C-only context

--- Begin Message --- Hello all. There is one other thing in Autoconf files of tcpslice and tcpdump that jumped out at me: savedcppflags="$CPPFLAGS" CPPFLAGS="$CPPFLAGS $V_INCLS" AC_CHECK_HEADERS(pcap/pcap-inttypes.h) AC_CHECK_FUNCS(pcap_lib_version) CPPFLAGS="$savedcppflags" It looks like

Re: [tcpdump-workers] AC_LBL_FIXINCLUDES does not make it into configure

--- Begin Message --- On Thu, 19 Jan 2023 15:57:30 -0800 Guy Harris wrote: > On Jan 19, 2023, at 3:20 PM, Denis Ovsienko > wrote: > > > * AC_LBL_SSLEAY -- is there anything useful to take from here? > > No, it's been replaced by the "Check for OpenSSL/libressl libcrypto" > code in

Re: [tcpdump-workers] AC_LBL_FIXINCLUDES does not make it into configure

--- Begin Message --- On Wed, 18 Jan 2023 15:53:21 -0800 Guy Harris wrote: > On Jan 18, 2023, at 3:32 PM, Denis Ovsienko via tcpdump-workers > wrote: > > > As it turns out, there is another unused macro > > (AC_LBL_HAVE_RUN_PATH), tcpslice became the first to

Re: [tcpdump-workers] AC_LBL_FIXINCLUDES does not make it into configure

--- Begin Message --- On Wed, 18 Jan 2023 09:22:28 -0500 Michael Richardson wrote: > I haven't heard a clear argument as to what autoconf/configure gets > us today over cmake, and maintaining both seems a huge waste of > energy. There's a comment buried in one of the build files: a release

Re: [tcpdump-workers] AC_LBL_FIXINCLUDES does not make it into configure

--- Begin Message --- On Tue, 17 Jan 2023 18:35:58 -0800 Guy Harris wrote: > If you're curious what AC_LBL_FIXINCLUDES is for, and why most > platforms don't need it, continue reading. Thank you for explaining the context Guy, it is very educational. Is AC_LBL_UNION_WAIT of a similar origin?

[tcpdump-workers] AC_LBL_FIXINCLUDES does not make it into configure

--- Begin Message --- Hello all. In tcpdump commit cee234c there are three messages changed in aclocal.m4, but only two messages changed in the resulting configure script. After a brief look it is clear that it is the third message (the one in AC_LBL_FIXINCLUDES) that does not make it to the

Re: [tcpdump-workers] [tcpdump] About HAVE_NO_PRINTF_Z

--- Begin Message --- On Thu, 12 Jan 2023 10:40:24 -0500 Michael Richardson wrote: > Denis Ovsienko via tcpdump-workers > wrote: > > Thank you for the detailed analysis, Guy. I did not realize > > the support is in the libc space rather than C99 space. Do you >

Re: [tcpdump-workers] [tcpdump] About HAVE_NO_PRINTF_Z

--- Begin Message --- On Thu, 12 Jan 2023 00:10:22 -0800 Guy Harris via tcpdump-workers wrote: > So, if we care about %z support: > > on UN*Xes, we'd have to drop support for OSes that don't > provide a C library that supports it; Thank you for the detailed analysis, Guy. I did not

Re: [tcpdump-workers] Autoconf with Debian patches

--- Begin Message --- On Sat, 7 Jan 2023 18:47:37 -0800 Guy Harris wrote: > On Jan 7, 2023, at 8:51 AM, Denis Ovsienko > wrote: > > > On Fri, 6 Jan 2023 17:13:20 -0800 > > Guy Harris wrote: > > > >> On Jan 6, 2023, at 3:31 PM, Denis Ovsienko > >> wrote: > >> > >>> It is the latter, and

Re: [tcpdump-workers] Has anyone got a clang-format for the tcpdump style?

--- Begin Message --- On Wed, 4 Jan 2023 08:40:21 -0500 Bill Fenner via tcpdump-workers wrote: > Hi, > > I know the tcpdump style follows a bunch of bsd patterns, since it > came from Berkeley in the first place. Does anyone have a > clang-format config that reflects these coding conventions?

Re: [tcpdump-workers] Autoconf with Debian patches

--- Begin Message --- On Fri, 6 Jan 2023 17:13:20 -0800 Guy Harris wrote: > On Jan 6, 2023, at 3:31 PM, Denis Ovsienko > wrote: > > > It is the latter, and a custom Autoconf seems an unreasonable > > requirement for contributing. > > Reasonable, or unreasonable? Unreasonable, if it is more

Re: [tcpdump-workers] Autoconf with Debian patches

--- Begin Message --- On Fri, 6 Jan 2023 14:49:54 -0800 Guy Harris wrote: > On Jan 6, 2023, at 2:24 PM, Denis Ovsienko > wrote: > > > On Fri, 6 Jan 2023 13:25:14 -0800 > > Guy Harris wrote: > > > >> If we switch to making Debian Autoconf the new standard and keeping > >> the generated

Re: [tcpdump-workers] Autoconf with Debian patches

--- Begin Message --- On Fri, 6 Jan 2023 13:25:14 -0800 Guy Harris wrote: > If we switch to making Debian Autoconf the new standard and keeping > the generated configure script in the repository, would that mean > that developers working from the repository would either have to > install Debian

[tcpdump-workers] Autoconf with Debian patches

--- Begin Message --- Hello all. As some have experienced before, attempts to regenerate the configure script often result in two groups of unnecessary changes (runstatedir and LARGE_OFF_T), both of which come from Debian-specific patches to Autoconf because traditionally the configure scripts

[tcpdump-workers] tcpdump 4.99.2 & libpcap 1.10.2

--- Begin Message --- Hello all. I hope this finds you well. tcpdump 4.99.2 and libpcap 1.10.2 are now available in the usual places, you can find the change logs below. This time it is a much larger amount of changes than usual because it has been about 1.5 years since the previous releases.

[tcpdump-workers] CI news November-December 2022

--- Begin Message --- Hello all. I hope this finds you well. Below you can find a digest of the CI infrastructure works since the previous update. * macOS CI has been switched from AMD64 to AArch64 following some infrastructure changes in Cirrus CI. Everything seems to work as before. * On

Re: [tcpdump-workers] Public Release of Z-Wave G.9959 TAP Specification

--- Begin Message --- On Tue, 6 Dec 2022 07:55:06 -0800 Chris Brandson via tcpdump-workers wrote: > Hello Denis, > > I agree with all of your suggestions, have made the changes and > pushed to the repo. Thank you Chris. I hope you don't mind one more question about the encoding. Would it be

Re: [tcpdump-workers] Public Release of Z-Wave G.9959 TAP Specification

--- Begin Message --- On Mon, 5 Dec 2022 11:53:11 -0800 Chris Brandson via tcpdump-workers wrote: > Hello everyone, > > We are pleased to publish the draft Z-Wave G.9959 TAP Specification [...] Hello Chris. Thank you for preparing the document. I am not familiar with the standard to make

[tcpdump-workers] macOS CI is switching from AMD64 to AArch64

--- Begin Message --- Hello all. Apparently, the current provider of macOS CI is switching their infrastructure from AMD64 to AArch64 (M1) by the end of this year, so tcpslice, tcpdump and libpcap are going to follow the suit, which will also upgrade macOS from 11 to either 12 or 13 (to be

[tcpdump-workers] CI news September-October 2022

--- Begin Message --- Hello list. I hope this finds you well. Below you can find a digest of the CI infrastructure works since the previous update. * OmniOS has seen some improvements to its Clang packages, so illumos-amd64 now uses Clang 15.0 (was 11.1). * netbsd-amd64 has been upgraded

[tcpdump-workers] tcpslice 1.6

--- Begin Message --- Hello list. tcpslice 1.6 has been released with the following change log. Thanks to everyone who contributed! - Call pcap_dump_close() on the output file. - Implement new flags in ./configure: --enable-instrument-functions, --without-libnids, --without-libosipparser2

Re: [tcpdump-workers] upcoming tcpslice release

--- Begin Message --- On Sat, 15 Oct 2022 15:21:42 -0700 Guy Harris wrote: > On Oct 15, 2022, at 8:03 AM, Denis Ovsienko via tcpdump-workers > wrote: > > > As it turns out, on Linux tcpslice currently fails to build with the > > current master branch of libpcap. This re

Re: [tcpdump-workers] upcoming tcpslice release

--- Begin Message --- As it turns out, on Linux tcpslice currently fails to build with the current master branch of libpcap. This reproduces in all Linux CI builds and also on my Ubuntu 20.04 PC. The root cause seems to be in libpcap via pcap-config: /usr/bin/ld: cannot find -lsystemd clang:

[tcpdump-workers] upcoming tcpslice release

--- Begin Message --- Hello list. Unless anyone objects, the next release of tcpslice (1.6) will be made soonish to flush the few buffered minor bugfixes and to take another item off my to-do list. -- Denis Ovsienko --- End Message --- ___

[tcpdump-workers] ARMv7 unaligned access

--- Begin Message --- Hello list. Based on some prior online research, I used to think that ARMv7 is a hardware that allows (by default or after simple tweaking) to terminate a userspace process when it tries to perform an unaligned memory access. Which is exactly the behaviour wanted for the CI

Re: [tcpdump-workers] configure script problem while working on extention

--- Begin Message --- On Sun, 14 Aug 2022 11:49:57 -0700 Guy Harris via tcpdump-workers wrote: > Or is this a ZIP archive provided by somebody other than tcpdump.org? github.com -> code -> download ZIP. I vaguely remember there was a "download tar.gz" there as well, but not anymore. Anyway,

[tcpdump-workers] CI news June-August 2022

--- Begin Message --- Hello list. Below you can find a digest of the CI infrastructure works since the previous update. * FreeBSD/AArch64 in release 13.1 notably improved its ability to run as a virtual machine, and freebsd-aarch64 has been migrated to OSU OSL infrastructure. Thanks to

Re: [tcpdump-workers] configure script problem while working on extention

--- Begin Message --- On Fri, 12 Aug 2022 16:27:29 +0200 Christian via tcpdump-workers wrote: > Then I opened the tcpdump.zip archive within the libpcap directory. > step into the directory, call ./configure and it build. success! The git clone of libpcap and the git clone of tcpdump are

Re: [tcpdump-workers] About formalization of pcap expressions

--- Begin Message --- On Sat, 23 Jul 2022 17:24:12 +0200 Francois-Xavier Le Bail via tcpdump-workers wrote: > Hi, > > FYI, the author of the following document try a formalization of pcap > expressions: > https://www.seas.upenn.edu/~nsultana/files/pcap_semantics.pdf In this > document,

Re: [tcpdump-workers] NetBSD CI breakage

--- Begin Message --- On Wed, 13 Jul 2022 23:16:18 -0700 Guy Harris wrote: > I changed it to a slightly different fix. Thank you. The signed device index hinted at some logic error, but I didn't understand if it required a more sophisticated fix. -- Denis Ovsienko --- End Message ---

[tcpdump-workers] NetBSD CI breakage

--- Begin Message --- Hello all. The last CI build of the libpcap-1.10 branch failed on netbsd-aarch64 because the latter now uses GCC 12. Commit 4e7f6e8 makes a lazy fix for that in the master branch; if a more sophisticated solution is not required, a simple cherry-pick into libpcap-1.10

Re: [tcpdump-workers] What's the correct new API to request pcap_linux to not open an eventfd

--- Begin Message --- On Fri, 1 Jul 2022 13:55:30 -0400 Bill Fenner via tcpdump-workers wrote: > If we set > pcap_nonblock after pcap_create and before pcap_activate, we get -3 - > which I don't get at all, unless, -3 means "you didn't activate the > pcap yet". My naive reading of the Linux

Re: [tcpdump-workers] endianness of portable BPF bytecode (DRAFT revision 4)

--- Begin Message --- Hello list. Below is revision 4 of the document, unless anyone objects it will be committed to libpcap repository soonish, this way any remaining improvements can be made there when and as necessary. Changes from the previous revision are as follows: * fixup letter case *

Re: [tcpdump-workers] endianness of portable BPF bytecode (DRAFT revision 3)

--- Begin Message --- Hello list. Below you can find the next draft revision. It incorporates some feedback received from Guy and Michael, also it reorders the TLVs and adds SnapLen TLV, Netmask TLV and EOF TLV. Also the text has been converted to a man page, so it could live next to

Re: [tcpdump-workers] NetBSD breakage

--- Begin Message --- On Thu, 12 Aug 2021 01:18:45 +0100 Denis Ovsienko via tcpdump-workers wrote: > On Wed, 11 Aug 2021 15:38:34 -0700 > Guy Harris wrote: > > > I've checked in a change to remove the include of grammar.h from > > gencode.c; it builds without problems on

Re: [tcpdump-workers] pcap_compile_nopcap() not in man pages

--- Begin Message --- On Wed, 12 Aug 2020 12:59:35 -0700 Guy Harris wrote: [...] > So, for now, my inclination is to 1) deprecate pcap_compile_nopcap() > (complete with marking it as deprecated, so code that uses it gets a > compile-time warning on compilers where the deprecation macro is >

Re: [tcpdump-workers] endianness of portable BPF bytecode

--- Begin Message --- On Sat, 11 Jun 2022 10:51:41 -0400 Michael Richardson wrote: > Denis Ovsienko via tcpdump-workers > wrote: > > Below is a draft of such a file format. It addresses the > > following needs: > > * There is a header with a signatu

Re: [tcpdump-workers] endianness of portable BPF bytecode

--- Begin Message --- On Fri, 10 Jun 2022 14:26:34 -0700 Guy Harris wrote: > On Jun 10, 2022, at 1:59 PM, Denis Ovsienko via tcpdump-workers > wrote: > > > Below is a draft of such a file format. It addresses the following > > needs: > > * There is a header with

Re: [tcpdump-workers] endianness of portable BPF bytecode

--- Begin Message --- On Thu, 2 Jun 2022 20:58:38 +0100 Denis Ovsienko via tcpdump-workers wrote: > If there is no convention in place yet, I would like to propose > declaring big-endian as the implicit/default byte order, then > particular file format(s) with headers can override that

[tcpdump-workers] BPF Exam

--- Begin Message --- Hello list. A while ago I tried to comprehend a few BPF-related bug reports in libpcap and found it difficult to follow the logic of filter compilation and optimization. On one hand, there is the universally available, but basic "tcpdump -d" pseudocode listing. On the

[tcpdump-workers] endianness of portable BPF bytecode

--- Begin Message --- Hello list. In the usual workflow a correct BPF expression eventually compiles to a series of BPF instructions, each of which is a 64-bit structure encoding the (opcode, jt, jf, k) tuple. So long as the compiled bytecode appears only between the OS kernel and libpcap, its

[tcpdump-workers] CI news January-May

--- Begin Message --- Hello list. Below you can find a digest of some works done on the CI infrastructure during past few months. First of all, the illumos-amd64 Buildbot worker has been replaced. It used to be an OpenIndiana VM from a commercial hosting provider. Several months ago the VM

[tcpdump-workers] WinPcap CI

--- Begin Message --- Hello list. www.winpcap.org has been down for a couple days, which is breaking libpcap CI in Appveyor. Now that Npcap is the recommended SDK, would it be a good occasion to stop doing CI with WinPcap? -- Denis Ovsienko --- End Message ---

[tcpdump-workers] project news January 2022

--- Begin Message --- Hello list. I almost typed "2021" into the subject of this e-mail, as 2022 still feels futuristic, yet it is here. Today is exactly 31 years from the first public release of tcpdump (2.0 by LBL), which at the time was still the same program as libpcap. As you can see on the

Re: [tcpdump-workers] Request for new LINKTYPE/DLT ZBOSS_NCP

--- Begin Message --- On Tue, 2 Nov 2021 09:46:30 +0300 Eugene Exarevsky via tcpdump-workers wrote: > Hi all, > > Please, allocate a new LINKTYPE/DLT called ZBOSS_NCP. > > The background is following: we (DSR) are developing Zigbee protocol > stack ZBOSS ( > The stack has serial commands

Re: [tcpdump-workers] Selectively suppressing CI on some sites for a commit?

--- Begin Message --- On Thu, 6 Jan 2022 23:35:30 -0800 Guy Harris wrote: [...] > It appears that a "GitHub skip hook" may have been first introduce in > Buildbot 0.9.11: > > https://docs.buildbot.net/0.9.11/relnotes/index.html > > with the hook being configurable by a regex match. The

Re: [tcpdump-workers] Selectively suppressing CI on some sites for a commit?

--- Begin Message --- On Thu, 6 Jan 2022 14:11:54 -0800 Guy Harris via tcpdump-workers wrote: > I've just updated the libpcap .appveyor.yml to get Npcap from > npcap.com (the Npcap site has been moved there); I added [skip > cirrus] to skip Cirrus CI for that change, and it appears to work.

Re: [tcpdump-workers] pcap_datalink_ex() in linktypes.html

--- Begin Message --- On Wed, 8 Dec 2021 23:02:58 + Denis Ovsienko via tcpdump-workers wrote: > I am going to merge the short Markdown file into the long HTML > page at some later point Alright, libpcap/doc/DLT_ALLOCATE_HOWTO.md has been merged into tcpdump-htdocs/linktypes.html

Re: [tcpdump-workers] pcap_datalink_ex() in linktypes.html

--- Begin Message --- On Sun, 28 Nov 2021 21:11:27 + Denis Ovsienko via tcpdump-workers wrote: > Hello all. > > Whilst updating some markup in linktypes.html, I wanted to change the [...] On a related note, it does not look right that linktypes.html in the middle of the explanati

Re: [tcpdump-workers] [libpcap] Keep Win32/Prj/* files ?

--- Begin Message --- On Mon, 6 Dec 2021 12:31:33 -0800 Guy Harris wrote: [...] > The CMake files are likely to be better maintained than the "use > Visual Studio directly" files, as you don't need Visual Studio, and > don't need to know how Visual Studio solution or project files work >

Re: [tcpdump-workers] [libpcap] Keep Win32/Prj/* files ?

--- Begin Message --- On Mon, 29 Nov 2021 19:20:32 +0100 Francois-Xavier Le Bail via tcpdump-workers wrote: > Hello, > > The information on building libpcap on Windows with Visual Studio is > here: > https://github.com/the-tcpdump-group/libpcap/blob/master/doc/README.Win32.md > (The supported

[tcpdump-workers] VLAN/MPLS FAQ

--- Begin Message --- Hello list. Whilst looking through tcpdump and libpcap issues, I noted that the specifics of "vlan" and "mpls" keywords in pcap filters is one of the most common causes of confusion. So it should be in the FAQ. That said, it is not clear if it would be better to have one

[tcpdump-workers] pcap_datalink_ex() in linktypes.html

--- Begin Message --- Hello all. Whilst updating some markup in linktypes.html, I wanted to change the reference to pcap_datalink_ex() into a hyperlink to respective man page, but it turned out there is no such function in libpcap in the first place. There is pcap_datalink_ext(), which has been

[tcpdump-workers] project news November 2021

--- Begin Message --- Hello list. I hope this finds you well. Below you can find an overview of assorted recent developments. The read-only git mirror service has moved from bpf.tcpdump.org to git.tcpdump.org. The latter works both as a browsable web-site and as a git clone URL (either https://

[tcpdump-workers] CI news September 2021 (RISC-V, illumos)

--- Begin Message --- Hello list. This is a semi-periodic summary of recent developments in the continuous integration space of the tcpdump group. It took a few months since Francois-Xavier Le Bail discovered this opportunity, but finally the Buildbot setup includes a hardware RISC-V worker,

Re: [tcpdump-workers] [tcpdump] Finding inconsistent outputs of tcpdump with different compilers

--- Begin Message --- On Mon, 9 Aug 2021 16:27:27 +0200 Francois-Xavier Le Bail via tcpdump-workers wrote: > cmp $TMPDIR/out1 $TMPDIR/out2 >/dev/null > [ $? = 1 ] && echo "$p" && diff $TMPDIR/out1 $TMPDIR/out2 && > echo Differential analysis is indeed a good solution when the

[tcpdump-workers] assorted build issues

--- Begin Message --- Hello list. I hope this finds you well. To follow up on the earlier point about the build problem space mapping, below are a few issues that don't fail building and testing, but might mean potential problems: * Builds that use Autoconf 2.71 generate quite a number of

Re: [tcpdump-workers] NetBSD breakage

--- Begin Message --- On Wed, 11 Aug 2021 15:38:34 -0700 Guy Harris wrote: > I've checked in a change to remove the include of grammar.h from > gencode.c; it builds without problems on macOS, and I suspect it will > build without problems everywhere Thank you, NetBSD has recovered now. I am

[tcpdump-workers] NetBSD breakage

--- Begin Message --- Hello list. I have spent some time looking into tcpdump NetBSD builds, which all have failed as a consequence of my libpcap commit 0c21cb27, which had broken the workaround earlier introduced in libpcap commit bb02779. As Guy has noted in a comment just now, the matter

Re: [tcpdump-workers] build failures on Solaris

--- Begin Message --- On Sun, 8 Aug 2021 12:02:53 -0700 Guy Harris wrote: [...] > I've checked in a change to explicitly tell CMake "this is a C-only > project, don't check for a C++ compiler", so it should now think it's > building 64-bit when building with GCC. > > See whether that fixes

Re: [tcpdump-workers] build failures on Solaris

--- Begin Message --- On Sun, 8 Aug 2021 01:22:09 -0700 Guy Harris wrote: [...] > I've checked in changes to: > > check the bit-width of the build in autotools; > > on Solaris, use the results of the bit-width checks for > autotools and CMake to figure out which version of

[tcpdump-workers] CI news July-August 2021

--- Begin Message --- Hello list. Besides the matters recently discussed on the list, a few notable developments in The Tcpdump Group CI took place since the previous update: * Another MIPS worker has been doing builds in the pool for a month. It runs a snapshot of NetBSD-current. Although

Re: [tcpdump-workers] build failures on Solaris

--- Begin Message --- On Mon, 2 Aug 2021 14:31:18 -0700 Guy Harris wrote: > solaris11$ /usr/bin/pcap-config --libs > -L/usr/lib -lpcap > solaris11$ /usr/bin/amd64/pcap-config --libs > -L/usr/lib/amd64 -R/usr/lib/amd64 -lpcap > > on my x86-64 Solaris 11 VM. $ uname -a

Re: [tcpdump-workers] build failures on Solaris

--- Begin Message --- On Sun, 1 Aug 2021 15:45:39 -0700 Guy Harris wrote: [...] > So where do the Solaris 11 hosts show up on the buildbot site? They don't. Solaris 9 and 11 are not in any CI at all. OpenCSW Buildbot runs on Solaris 10, but uses a single build script. I used OpenCSW shell

Re: [tcpdump-workers] build failures on Solaris

--- Begin Message --- On Sat, 31 Jul 2021 14:55:32 -0700 Guy Harris wrote: [...] > What version of CMake is being used, and how was it installed? > > My Solaris 11 x86-64 virtual machine has CMake 2.8.6 in > /usr/ccs/bin/cmake, installed from Sun^WOracle's Image Packaging > System repositories,

[tcpdump-workers] build failures on Solaris

--- Begin Message --- On Sat, 24 Jul 2021 00:11:27 +0100 Denis Ovsienko via tcpdump-workers wrote: > There are more related corner cases of varying severity, > some of which I might have time to describe later. So, as promised... Several warnings are now documented in the build scripts

Re: [tcpdump-workers] compiler warnings on AIX and Solaris

--- Begin Message --- On Sat, 24 Jul 2021 10:55:19 -0700 Guy Harris wrote: [...] > If there's a way to force XL C to treat it as a hard error, we need > to update the AC_LBL_CHECK_UNKNOWN_WARNING_OPTION_ERROR autoconf > macro to set the compiler up to use it when testing whether compiler >

Re: [tcpdump-workers] compiler warnings on AIX and Solaris

--- Begin Message --- [...] > So the only way to fix this is to turn off the warnings; change > 39f09d68ce7ebe9e229c9bf5209bfc30a8f51064 adds macros to disable and > re-enable -Wcast-qual and wraps the offending code in getopt_long.c > with those macros, so the problem should be fixed on Solaris

[tcpdump-workers] compiler warnings on AIX and Solaris

--- Begin Message --- Hello list. As it turns out, on Solaris 9 it is impossible to compile current tcpdump with CFLAGS=-Werror because missing/getopt_long.c yields a few warnings (attached). As far as the current revisions of this file go in FreeBSD, NetBSD and OpenBSD, FreeBSD seems to be the

[tcpdump-workers] CI news June 2021

--- Begin Message --- Hello list. I hope you have a nice summer weekend. Below you can find a digest of improvements made in the Buildbot infrastructure in the last couple months. * After some OS shuffling one more worker had moved from my home lab to OSU OSL. As a result, linux-aarch64 became

Re: [tcpdump-workers] CI status update

--- Begin Message --- On Mon, 5 Apr 2021 10:42:39 +0100 Denis Ovsienko via tcpdump-workers wrote: > Hello list. > > I hope you have a great day. Please find below a brief overview of > some current continuous integration matters. Please find below a few recent developments si

[tcpdump-workers] CI status update

--- Begin Message --- Hello list. I hope you have a great day. Please find below a brief overview of some current continuous integration matters. The Linux/s390x problem space is now covered with the IBM Z CI service provided by Oregon State University Open Source Lab. It uses Jenkins and is not

Re: [tcpdump-workers] ARM build slaves (tcpdump mirror in Germany)

--- Begin Message --- On Wed, 24 Mar 2021 00:52:00 +0100 Harald Welte wrote: > Hi Denis, > > On Tue, Mar 23, 2021 at 12:35:06AM +0000, Denis Ovsienko via > tcpdump-workers wrote: > > That's great, three worker types are ready to go anytime soon, just > > decide which

Re: [tcpdump-workers] ARM build slaves (tcpdump mirror in Germany)

--- Begin Message --- On Mon, 22 Mar 2021 19:00:31 +0100 Harald Welte wrote: > Dear Denis, > > On Sun, Mar 21, 2021 at 11:08:44PM +0000, Denis Ovsienko via > tcpdump-workers wrote: > > Thank you for the offer. For the operating systems specifics please > >

Re: [tcpdump-workers] tcpdump mirror in Germany

--- Begin Message --- On Sun, 21 Mar 2021 22:04:29 +0100 Harald Welte via tcpdump-workers wrote: > My company sysmocom is running build and test infrastructure for > osmocom.org, and we'd be more than happy to host those ARM build > slaves in Germany. We also operate a number of rpi4 for jenkins

Re: [tcpdump-workers] tcpdump mirror in Germany

--- Begin Message --- On Sat, 20 Mar 2021 18:34:34 +0100 Jan Prunk via tcpdump-workers wrote: > Hello, > > I am offering to provide tcpdump mirror in Germany. Are you > interested? Thank you for the offer, but a mirror would not solve any existing problem. Would you like to host any of the

Re: [tcpdump-workers] continuous integration status update

--- Begin Message --- On Thu, 4 Mar 2021 00:42:23 -0800 Guy Harris wrote: > On Mar 3, 2021, at 2:30 PM, Denis Ovsienko via tcpdump-workers > wrote: > > > A partial replacement for that service is ci.tcpdump.org, which is a > > buildbot instance doing Linux AArch64 buil

Re: [tcpdump-workers] continuous integration status update

--- Begin Message --- On Fri, 12 Feb 2021 16:18:10 + Denis Ovsienko via tcpdump-workers wrote: [...] > The Travis CI subscription will cease in early March (unless there is > a sponsor willing to pay 82.80 USD per month). At this time the > impact of that would be the following: >

[tcpdump-workers] continuous integration status update

--- Begin Message --- Hello list. The tcpdump group repositories used to rely mainly on travis-ci.org for free continuous integration. For many years Travis CI GmbH had been making an outstanding contribution to the worldwide open source community, so let's thank all the people who at the time

Re: [tcpdump-workers] Stick with Travis for continuous integration, or switch?

--- Begin Message --- On Mon, 18 Jan 2021 22:29:21 -0800 Guy Harris via tcpdump-workers wrote: > I guess we meet those requirements, although I'm not too keen on > having to keep going hat-in-hand to them every time we run out of > credits; hopefully, we can just get a renewable amount. I had

Re: [tcpdump-workers] Stick with Travis for continuous integration, or switch?

--- Begin Message --- On Mon, 18 Jan 2021 22:29:21 -0800 Guy Harris via tcpdump-workers wrote: > So we can either migrate to travis-ci.com or use other providers. Travis has been downsizing the .org server pool for a couple weeks, so far it has went from 370 to 250 with apparent effect on the

Re: [tcpdump-workers] libpcap detection and linking in tcpdump

--- Begin Message --- On Wed, 9 Sep 2020 17:07:25 +0100 Denis Ovsienko via tcpdump-workers wrote: > Here are my steps to reproduce: > > libpcap$ ./configure --enable-remote --prefix=/tmp/libpcap > libpcap$ make > libpcap$ make install > tcpdumpbuild$ cmake

Re: [tcpdump-workers] Stick with Travis for continuous integration, or switch?

--- Begin Message --- On Thu, 21 Jan 2021 08:15:33 +0100 Dagobert Michelsen wrote: > Hi folks, > > Am 21.01.2021 um 04:24 schrieb Denis Ovsienko via tcpdump-workers > : > >>s390x (a/k/a z/Architecture, i.e. S/3x0-64) - a big-endian > >> platform, so we ca

Re: [tcpdump-workers] Stick with Travis for continuous integration, or switch?

--- Begin Message --- On Mon, 18 Jan 2021 22:29:21 -0800 Guy Harris via tcpdump-workers wrote: > Travis CI is announcing on the travis-ci.org site that "... > travis-ci.org will be shutting down in several weeks, with all > accounts migrating to travis-ci.com. Please stay tuned here for more >

[tcpdump-workers] longjmp() conversion progress

--- Begin Message --- Hello list. As a follow-up to the comments Bill had made a few days ago, please find below the current progress of the longjmp() conversion, which was earlier discussed in great detail on the list. I might post updated versions of this report in future if (and only if) there

Re: [tcpdump-workers] libpcap detection and linking in tcpdump

--- Begin Message --- On Thu, 7 Jan 2021 16:46:41 -0800 Guy Harris wrote: > 3.1 dates back to 2015. That might be sufficient to treat as a > minimum. 5 years of backward compatibility might be OK'ish, although from time to time I run into such "long-term support" systems that in practice mean

Re: [tcpdump-workers] [tcpdump] After setjmp/longjmp update

--- Begin Message --- On Mon, 4 Jan 2021 12:35:29 -0500 Bill Fenner via tcpdump-workers wrote: > I just wanted to share some of my thinking about how to proceed with > the truncation-related changes on the road to 5.0.0. > > 1. Improve code coverage for the printer that's being modified. (This

Re: [tcpdump-workers] tcpdump build doc for Windows

--- Begin Message --- On Sun, 3 Jan 2021 14:23:40 -0800 Guy Harris wrote: [...] > They're both reasonably up-to-date (they both mention Npcap and the > use of CMake), but the latter is more detailed. > > I'll check whether the first document says anything that's not > mentioned in the second,

[tcpdump-workers] tcpdump build doc for Windows

--- Begin Message --- Hello list. tcpdump source tree has a short file named "Readme.Win32", which was mostly updated on 8 Aug 2019, and a longer file named "doc/README.Win32.md", which was mostly updated on 5 Feb 2020. These seem to provide somewhat different instructions, perhaps it would be a

Re: [tcpdump-workers] Custom decoding offset? (for batman-adv)

--- Begin Message --- On Fri, 6 Nov 2020 14:34:12 +0100 Linus Lüssing via tcpdump-workers wrote: [...] > Which suggests something like: > > $ tcpdump -i eth0 -w - | editcap -C 82 - - | tcpdump -r - > > However, ideally I would like to use a custom offset in a project > based on libpcap: > >

Re: [tcpdump-workers] libpcap error codes?

--- Begin Message --- On Wed, 7 Oct 2020 14:37:41 -0700 Guy Harris via tcpdump-workers wrote: [...] > A new API could be added that returns a PCAP_ERROR_ value rather than > -1 on error (so as not to break source or binary compatibility with > code using the existing APIs). Do you mean to

Re: [tcpdump-workers] [tcpdump] After setjmp/longjmp update

--- Begin Message --- On Fri, 25 Sep 2020 03:04:21 +0100 Denis Ovsienko via tcpdump-workers wrote: [...] > == Summary: the method seems to work well, there is a clean reference > implementation, it should be easy to apply to other printers that > implement similar encodings,

Re: [tcpdump-workers] [tcpdump] After setjmp/longjmp update

--- Begin Message --- On Thu, 17 Sep 2020 15:15:25 +0100 Denis Ovsienko via tcpdump-workers wrote: > On Sat, 5 Sep 2020 18:20:42 +0200 > Francois-Xavier Le Bail via tcpdump-workers > wrote: > > > 2) Process all the truncated cases with: > > ndo->ndo_ll_h

  1   2   >