Re: [tcpdump-workers] Link Layer Type Request NETANALYZER_NG

--- Begin Message --- On Mar 24, 2021, at 12:32 AM, Jan Adam wrote: >> So, with incl_len equal to {PayloadSize,VarSize} + 54, orig_len would be >> equal to {original PayloadSize} + 54, so the original payload size would be >> orig_len - 54. >> >> That would allow the original size and the slic

[tcpdump-workers] Rough consensus and quiet humming

--- Begin Message --- https://twitter.com/MeghanEMorris/status/1382109954224521216/photo/1 --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

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

--- Begin Message --- On Jul 23, 2021, at 4:11 PM, Denis Ovsienko via tcpdump-workers wrote: > 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

Re: [tcpdump-workers] build failures on Solaris

--- Begin Message --- On Jul 31, 2021, at 3:37 AM, Denis Ovsienko via tcpdump-workers wrote: > # Solaris 11 with GCC # > This is the opposite: the pre-compile libpcap feature test programs > fail to link so all libpcap feature tests fail. However, libpcap is > detected as available and t

Re: [tcpdump-workers] build failures on Solaris

--- Begin Message --- On Jul 31, 2021, at 4:35 PM, Denis Ovsienko wrote: > 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, ins

Re: [tcpdump-workers] build failures on Solaris

--- Begin Message --- On Aug 1, 2021, at 6:08 PM, Denis Ovsienko wrote: > On Sun, 1 Aug 2021 15:45:39 -0700 > Guy Harris wrote: > >> Probably some annoying combination of one or more of "different >> compilers", "later version of CMake", "at least some versions of cc >> and gcc build 32-bit bin

Re: [tcpdump-workers] build failures on Solaris

--- Begin Message --- On Jul 31, 2021, at 3:37 AM, Denis Ovsienko via tcpdump-workers wrote: > # Solaris 11 with GCC # > This is the opposite: the pre-compile libpcap feature test programs > fail to link so all libpcap feature tests fail. However, libpcap is > detected as available and t

Re: [tcpdump-workers] build failures on Solaris

--- Begin Message --- On Aug 3, 2021, at 12:07 AM, Dagobert Michelsen wrote: > The /64 suffix in bin/ and lib/ is a symlink to the respective architecture > and simplifies cross-platform build between Sparc and x86. For whatever reason, /usr/bin/64 isn't present on my Solaris 11.3 (x86-64) VM:

Re: [tcpdump-workers] build failures on Solaris

--- Begin Message --- On Jul 31, 2021, at 3:37 AM, Denis Ovsienko via tcpdump-workers wrote: > # Solaris 11 with GCC # > This is the opposite: the pre-compile libpcap feature test programs > fail to link so all libpcap feature tests fail. However, libpcap is > detected as available and t

Re: [tcpdump-workers] build failures on Solaris

--- Begin Message --- On Aug 8, 2021, at 2:26 AM, Denis Ovsienko wrote: > GCC+CMake fails early now (see attached). Good! That reveals the *underlying* problem: 1) CMake, by default, checks for both a C *and* a C++ compiler; 2) if it's checking for both compilers, the way CMake determines CM

Re: [tcpdump-workers] NetBSD breakage

--- Begin Message --- On Aug 11, 2021, at 3:09 PM, Denis Ovsienko via tcpdump-workers wrote: > The other matter is that the gencode.h/grammar.h pair works best when > it is included early. Perhaps the gencode.h/grammar.h pair works best when it doesn't include grammar.h. :-) I've checked in a

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

--- Begin Message --- On Dec 6, 2021, at 10:55 AM, Denis Ovsienko via tcpdump-workers wrote: > On Mon, 29 Nov 2021 19:20:32 +0100 Francois-Xavier Le Bail via > tcpdump-workers wrote: > >> Does anyone use these files? >> Win32/Prj/wpcap.sln >> Win32/Prj/wpcap.vcxproj >> Win32/Prj/wpcap.vcxproj

Re: [tcpdump-workers] New DLT_ type request

--- Begin Message --- On Jan 5, 2022, at 9:38 AM, Timotej Ecimovic via tcpdump-workers wrote: > I'm requesting an addition of the new DLT type. I'd call it: > DLT_SILABS_DEBUG_CHANNEL. > The description of the protocol is here: > https://github.com/SiliconLabs/java_packet_trace_library/blob/mas

Re: [tcpdump-workers] New DLT_ type request

--- Begin Message --- On Jan 5, 2022, at 6:53 PM, Timotej Ecimovic wrote: > No. Like the document describes: tooling that deals with deframing is > expected to remove the starting `[`, the ending `]` and the 2 byte length > right after the `[`. > In case of creating a PCAPNG file out of this s

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

--- Begin Message --- 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. Are there other comments to add to suppress OpenCSW CI and to suppress the other

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

--- Begin Message --- On Jan 6, 2022, at 3:00 PM, Denis Ovsienko via tcpdump-workers wrote: > 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 sit

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

--- Begin Message --- On Jan 6, 2022, at 3:22 PM, Guy Harris via tcpdump-workers wrote: > On Jan 6, 2022, at 3:00 PM, Denis Ovsienko via tcpdump-workers > wrote: > >> Do you think https://www.tcpdump.org/ci.html should document [skip cirrus] >> and [skip appveyor]

Re: [tcpdump-workers] wireshark extension for a Kernel Module (like Usbmon)

--- Begin Message --- On Mar 7, 2022, at 5:55 AM, Christian via tcpdump-workers wrote: > hello out there, I created a kernel probe module and I want to watch the > outputs of that module with pcap/Wireshark or tcpdump... Just like > usbmon. My prefered tool is dumpcap. So I defined a char device

Re: [tcpdump-workers] Speed specific Link-Layer Header Types for USB 2.0

--- Begin Message --- On May 8, 2022, at 4:48 AM, Tomasz Moń via tcpdump-workers wrote: > I would like to remedy the situation by requesting additional speed > specific link layer header types, for example: > * LINKTYPE_USB_2_0_LOW_SPEED > * LINKTYPE_USB_2_0_FULL_SPEED > * LINKTYPE_USB_2_0_HI

Re: [tcpdump-workers] Speed specific Link-Layer Header Types for USB 2.0

--- Begin Message --- On May 8, 2022, at 1:30 PM, Michael Richardson wrote: > I guess I would have thought that a physical bus could have a mix of > different devices which operate at different speeds. As such, I wondered if > you really needed pcapng to be able to mix LINKTYPES in the same file

Re: [tcpdump-workers] Speed specific Link-Layer Header Types for USB 2.0

--- Begin Message --- On May 8, 2022, at 10:47 PM, Tomasz Moń wrote: > On Sun, May 8, 2022 at 8:53 PM Guy Harris wrote: >> At least from a quick look at section 5.2.3 "Physical Bus Topology" of the >> USB 2.0 spec, a given bus can either be a high-speed bus or a full/low-speed >> bus. > > The

Re: [tcpdump-workers] Speed specific Link-Layer Header Types for USB 2.0

--- Begin Message --- On May 8, 2022, at 11:09 PM, Tomasz Moń wrote: > Note that end nodes cannot directly communicate with each other. The > communication is always between host and a device. Those two sentences, when combined, imply that either 1) a host is not an end node or

Re: [tcpdump-workers] Speed specific Link-Layer Header Types for USB 2.0

--- Begin Message --- On May 9, 2022, at 1:33 AM, Tomasz Moń wrote: > On Mon, May 9, 2022 at 9:21 AM Guy Harris wrote: >> On May 8, 2022, at 11:09 PM, Tomasz Moń wrote: >> >>> Device to device communication is not possible. >> >> Is the idea that the topology of USB is a tree, with the host a

Re: [tcpdump-workers] Speed specific Link-Layer Header Types for USB 2.0

--- Begin Message --- On May 9, 2022, at 1:58 AM, Tomasz Moń wrote: > On Mon, May 9, 2022 at 9:17 AM Guy Harris wrote: >> On May 8, 2022, at 10:47 PM, Tomasz Moń wrote: >>> On Sun, May 8, 2022 at 8:53 PM Guy Harris wrote: At least from a quick look at section 5.2.3 "Physical Bus Topology"

Re: [tcpdump-workers] Speed specific Link-Layer Header Types for USB 2.0

--- Begin Message --- On May 9, 2022, at 7:41 AM, Tomasz Moń wrote: > That would require defining pseudoheader that would have to be included > in every packet. Is that really a great burden? > And it would only solve the corner case that the > currently available open-source friendly sniffers

Re: [tcpdump-workers] Speed specific Link-Layer Header Types for USB 2.0

--- Begin Message --- On May 9, 2022, at 12:40 PM, Tomasz Moń wrote: > On Mon, 2022-05-09 at 12:02 -0700, Guy Harris wrote: >> On May 9, 2022, at 7:41 AM, Tomasz Moń wrote: >> >>> That would require defining pseudoheader that would have to be >>> included in every packet. >> >> Is that really

Re: [tcpdump-workers] Speed specific Link-Layer Header Types for USB 2.0

--- Begin Message --- On May 9, 2022, at 12:31 PM, Tomasz Moń wrote: > There is no such thing as "low-speed bus" because low-speed is only > allowed for non-hub devices. USB hosts and hubs *must* support atleast > full and high speed. USB devices are allowed to be low-speed (such > devices can op

Re: [tcpdump-workers] Speed specific Link-Layer Header Types for USB 2.0

--- Begin Message --- On May 9, 2022, at 1:02 PM, Tomasz Moń wrote: > The same as why URB level captures are confusing. Maybe not to the same > level as that would be just a single byte (and the URB metadata > contains way more information), but it would still raise the questions > like "where in

Re: [tcpdump-workers] Speed specific Link-Layer Header Types for USB 2.0

--- Begin Message --- On May 9, 2022, at 9:41 PM, Tomasz Moń wrote: > On Mon, 2022-05-09 at 13:19 -0700, Guy Harris wrote: >> On May 9, 2022, at 1:02 PM, Tomasz Moń wrote: >> >>> "Why this doesn't match all the documents on USB that I have >>> read?". >> >> What is the "this" that wouldn't mat

Re: [tcpdump-workers] Speed specific Link-Layer Header Types for USB 2.0

--- Begin Message --- On May 9, 2022, at 10:05 PM, Tomasz Moń wrote: > On Tue, May 10, 2022 at 6:57 AM Guy Harris wrote: >> On May 9, 2022, at 9:41 PM, Tomasz Moń wrote: >>> Also Wireshark would have to show "USB Full/Low speed capture" section with >>> only the single byte denoting >>> full o

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

--- Begin Message --- On May 20, 2022, at 10:56 AM, Bill Fenner via tcpdump-workers wrote: > I'm helping to debug a system that uses many many pcap handles, and never > calls pcap_loop - only ever pcap_next. Both pcap_loop() and pcap_next() ultimately go to the same place. Note, BTW, that pcap

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

--- Begin Message --- 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 a signature string to avoid false positive > detection as some other file type that begins exact

Re: [tcpdump-workers] RFC: TLS in rpcaps

--- Begin Message --- On Jul 4, 2022, at 4:49 PM, Ryan Castellucci via tcpdump-workers wrote: > 1) TLS compression support is a foot-bazooka, is exploitable in practice, and > should be removed. A modified version of the CRIME[1] attack should be > completely feasible. I can't imagine any remo

Re: [tcpdump-workers] NetBSD CI breakage

--- Begin Message --- On Jul 10, 2022, at 2:48 PM, Denis Ovsienko via tcpdump-workers wrote: > 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 sol

Re: [tcpdump-workers] [tcpdump] About struct in_addr / struct in6_addr

--- Begin Message --- On Jul 17, 2022, at 10:10 AM, Francois-Xavier Le Bail via tcpdump-workers wrote: > The current nd_ipv4 and nd_ipv6 types were added in 2017 for alignment > reasons. > > Since then, > most of the 'struct in_addr' were replaced by 'nd_ipv4', > most of the 'struct in6_addr'

Re: [tcpdump-workers] [tcpdump] About struct in_addr / struct in6_addr

--- Begin Message --- On Jul 17, 2022, at 11:09 AM, Francois-Xavier Le Bail wrote: > Remain some stuff about 'struct in6_addr'. Any need to keep them? > > $ git grep -l 'struct in6_addr' > CMakeLists.txt > cmakeconfig.h.in > config.h.in > configure > configure.ac > netdissect-stdinc.h That's t

Re: [tcpdump-workers] [tcpdump] About struct in_addr / struct in6_addr

--- Begin Message --- On Jul 17, 2022, at 3:39 PM, Bill Fenner wrote: > IMO it is safe to drop support for OSes lacking native IPv6 support. Yeah. Back when IPv6 support was added to tcpdump, it was an experimental new technology and the configure script had to figure out which of several add-

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

--- Begin Message --- On Aug 12, 2022, at 7:27 AM, Christian via tcpdump-workers wrote: > I pick up this thread of mine again from 7th march of this year (wireshark > extension for a Kernel Module (like Usbmon)​ ) enhanced with a configure > issue, Unless I've missed something, "again" means

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

--- Begin Message --- On Aug 15, 2022, at 12:50 AM, Denis Ovsienko via tcpdump-workers wrote: > 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 -&

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

--- Begin Message --- What are the contents of config.log? --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

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

--- Begin Message --- On Aug 15, 2022, at 1:37 PM, Christian wrote: > configure:6075: checking for pcap_loop > configure:6075: gcc -o conftest -g -O2 conftest.c -L/usr/local/lib > -Wl,-rpath,/usr/local/lib -lpcap >&5 > /usr/bin/ld: /usr/local/lib/libpcap.so: undefined reference to > `scsimon

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

--- Begin Message --- On Aug 16, 2022, at 12:49 PM, Christian wrote: >>> configure:6075: checking for pcap_loop >>> configure:6075: gcc -o conftest -g -O2 conftest.c -L/usr/local/lib >>> -Wl,-rpath,/usr/local/lib -lpcap >&5 >>> /usr/bin/ld: /usr/local/lib/libpcap.so: undefined reference to >

Re: [tcpdump-workers] DLT type for Libpcap Library

--- Begin Message --- On Aug 24, 2022, at 11:31 AM, Christian via tcpdump-workers wrote: > Hello everyone, another question that I have is which DLT-type I should use > for my libpcap-module. Since Im writing a module which acquires data from a > kernel module, which in turn has no IP-based pa

Re: [tcpdump-workers] DLT type for Libpcap Library

--- Begin Message --- On Aug 29, 2022, at 6:13 AM, Christian wrote: >> "Defined" in what sense? > > First of all, I want to define a header, with a magic byte maybe, a time > stamp, length of the whole packet and so on. Something which wraps my actual > data and which libpcap can recognize or

Re: [tcpdump-workers] upcoming tcpslice release

--- Begin Message --- 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 reproduces in all Linux CI > builds and also on my Ubuntu 20.04 PC. The root cause seems

Re: [tcpdump-workers] Resend: Request for new DLT Value

--- Begin Message --- On Nov 15, 2022, at 3:50 PM, Chris Brandson via tcpdump-workers wrote: > The ITU Recommendation G.9959 document can be found here > https://www.itu.int/rec/T-REC-G.9959 . > Work is ongoing on a wireshark dissector (hence the request f

Re: [tcpdump-workers] Autoconf with Debian patches

--- Begin Message --- On Jan 4, 2023, at 2:30 PM, Denis Ovsienko via tcpdump-workers wrote: > 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

Re: [tcpdump-workers] Autoconf with Debian patches

--- Begin Message --- 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 configure script in the repository, would that mean >> that developers workin

Re: [tcpdump-workers] Autoconf with Debian patches

--- Begin Message --- 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? Whatever version is chosen as the standard autoconf, if the goal is to have the version of the co

Re: [tcpdump-workers] Autoconf with Debian patches

--- Begin Message --- 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 a custom Autoconf seems an unreasonable >>> requirement for contributing. >>

Re: [tcpdump-workers] Autoconf with Debian patches

--- Begin Message --- On Jan 8, 2023, at 5:24 AM, Denis Ovsienko wrote: > Thank you for this information. Let me add that Ubuntu 20.04 defaults > to 2.69, but Ubuntu 22.04, FreeBSD, NetBSD, OpenBSD and OmniOS all > currently default to Autoconf 2.71. ...and macOS doesn't ship with autoconf in t

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

--- Begin Message --- On Jan 11, 2023, at 10:44 PM, Francois-Xavier Le Bail via tcpdump-workers wrote: > The commit fbd44158e0d5e6bb0c9b05671f702ebcf68cc56d was: > --- >Mend "make check" on Solaris 9 (Autoconf only).

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

--- Begin Message --- On Jan 11, 2023, at 11:06 PM, Guy Harris via tcpdump-workers wrote: > On UN*Xes, the C library is typically the system API library, so it's bundled > with the OS rather than the compiler, so I don't know whether this is an > issue of Sun C 5.9 or Sun

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

--- Begin Message --- On Jan 17, 2023, at 3:13 PM, Denis Ovsienko via tcpdump-workers wrote: > 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 messa

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

--- Begin Message --- On Jan 18, 2023, at 1:07 AM, Denis Ovsienko wrote: > Thank you for explaining the context Guy, it is very educational. A significant part of what's in autoconf, and a significant part of what's in at least some configure scripts, dates back to old UN*Xes. ISO C and POSIX

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

--- Begin Message --- 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 lose this luggage. Unused in libpcap back to 0.4 and tcpdump back to 3.4, so it may be another one

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

--- Begin Message --- 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 configure.ac.--- End Message --- ___

Re: [tcpdump-workers] [OPSAWG] I-D Action: draft-ietf-opsawg-pcapng-00.txt

--- Begin Message --- On Jan 24, 2023, at 2:02 PM, Michael Richardson wrote: > With this document adoption, we finally have all the PCAP related documents > in the DT. One thing that was mentioned to me is that the PCAPNG document > has an IANA Registry for Block Type Codes. > > The document i

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

--- Begin Message --- 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. Interestingly, tcpslice and tcpdump, > which don't call pfopen(), used to have this substitute, and

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

--- Begin Message --- On Jan 28, 2023, at 2:01 PM, Denis Ovsienko via tcpdump-workers wrote: > 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, ra

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

--- Begin Message --- On Feb 2, 2023, at 7:42 AM, Paschal Chukwuebuk Amusuo via tcpdump-workers wrote: > 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 packets befor

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

--- Begin Message --- On Jan 27, 2023, at 4:53 AM, Denis Ovsienko wrote: > On Fri, 27 Jan 2023 01:40:48 -0800 > Guy Harris wrote: > >> *don't* support C99 inline? If not, we could just remove the call >> from configure.ac and the definition from aclocal.m4. > > In 2002 in commit b1263c6 you w

<    1   2