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

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

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,

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,

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

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] 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

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 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

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 SunOS 5.9 (th

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

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

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 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

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

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] 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

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] 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] 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

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] 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 >

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 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 --- 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] [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

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

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] 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

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

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

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

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

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

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

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

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 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 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

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

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 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. > >

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

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 > *

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

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] 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 site has

[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] 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

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: >

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 >>

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

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

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

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

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

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,

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

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

[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] 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

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

--- Begin Message --- On Mar 22, 2021, at 5:35 PM, Denis Ovsienko via tcpdump-workers wrote: > On Mon, 22 Mar 2021 19:00:31 +0100 > Harald Welte wrote: ... >> btw: I'm not sure if qemu full system emulation of e.g. ppc on a >> x86_64 hardware would be an option, though. I think >>

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

--- Begin Message --- On Mar 22, 2021, at 7:33 AM, Jan Adam wrote: >> Are they aligned on natural boundaries? > > No, it is not aligned but packet. We use #pragma pack(1) for the footer > structure. You should probably add that to the page with the structure definition. >> What do the four

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

--- Begin Message --- On Mar 15, 2021, at 9:04 AM, Jan Adam wrote: >> Can the variable be anything *other* than a packet of some sort? > > There are only the mentioned 5 representations planned for pcap files since > this is what our capture device may capture into a pcap file. The >

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

--- Begin Message --- On Mar 12, 2021, at 4:35 AM, Jan Adam wrote: >> So is "the variable" the same thing as "the payload"? > > That is correct. To be more specific the payload is the value/content of the > variable. Can the variable be anything *other* than a packet of some sort? The

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

--- Begin Message --- On Mar 8, 2021, at 12:07 AM, Jan Adam via tcpdump-workers wrote: > We have created a public document on our website You can point to for the > description. > > Here is the link: https://kb.hilscher.com/x/brDJBw > > It contains a more detailed description of the fields

Re: [tcpdump-workers] continuous integration status update

--- Begin Message --- 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 builds for the github.com > repositories. So where is that hosted? Are you hosting it

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

--- Begin Message --- On Mar 3, 2021, at 8:58 AM, Jan Adam via tcpdump-workers wrote: > for our new analysis product netANALYZER NG I would like to request a new > link-layer type value. > > NETANALYZER_NG > > The new Link-Layer-Type format is described as following: > > Next-generation

Re: [tcpdump-workers] Request for new LINKTYPE_* code LINKTYPE_AUERSWALD_LOG

--- Begin Message --- On Feb 4, 2021, at 3:41 AM, developer--- via tcpdump-workers wrote: > We currently use this code in our lua dissector to display (decoded) SIP > messages. > > -- offsets will change with the new LINKTYPE >if (buf(148,2):uint() == MSG_TYPE_SIP) then >

Re: [tcpdump-workers] Request for new LINKTYPE_* code LINKTYPE_AUERSWALD_LOG

--- Begin Message --- On Feb 3, 2021, at 6:54 AM, developer--- via tcpdump-workers wrote: > We would like to request a dedicated LINKTYPE_* / DLT_* code. > Auerswald is a major German telecommunications equipment manufacturer. > We have implemented the option to capture (combined) network

Re: [tcpdump-workers] Request to add MCTP and PCI_DOE to PCAP link type

--- Begin Message --- On Dec 16, 2020, at 8:09 PM, Yao, Jiewen via tcpdump-workers wrote: > We did a prototype for the SpdmDump tool > (https://github.com/jyao1/openspdm/blob/master/Doc/SpdmDump.md). We can > generate a PCAP file and parse it offline. > In our prototype, we use below

Re: [tcpdump-workers] Request to add MCTP and PCI_DOE to PCAP link type

--- Begin Message --- On Dec 16, 2020, at 8:09 PM, Yao, Jiewen via tcpdump-workers wrote: > I write this email to request to below 2 link types. > > > 1. MCTP ... > MCTP packet is defined in DMTF PMCI working group Management Component > Transport Protocol (MCTP) Base >

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

--- Begin Message --- On Jan 22, 2021, at 7:11 PM, Guy Harris via tcpdump-workers wrote: > I'll try experimenting with one of my Ubuntu VMs. Welcome to Shared Library Search Hell. Most UN*Xes have a notion of RPATH (with, of course, different compiler command-line flags to set it). p

Re: [tcpdump-workers] Any way to filter ether address when type is LINUX_SLL?

--- Begin Message --- On Jan 21, 2021, at 8:41 AM, Bill Fenner via tcpdump-workers wrote: > It would be perfectly reasonable (and fairly straightforward) to update > libpcap to be able to filter on the Ethernet address in DLT_LINUX_SLL or > DLT_LINUX_SLL2 mode. Link-layer address, to be more

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

--- Begin Message --- On Jan 22, 2021, at 2:54 PM, Denis Ovsienko via tcpdump-workers wrote: > I have tested it again with the current master branches of libpcap and > tcpdump. Both builds (with and without libpcap0.8-dev) now complete > without errors. > > However, in both cases the installed

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

--- Begin Message --- 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 information." They don't provide any information there. However, at

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

--- Begin Message --- On Jan 7, 2021, at 5:41 PM, Denis Ovsienko via tcpdump-workers wrote: > 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 someone keeps paying good money for "support" for

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

--- Begin Message --- On Jan 7, 2021, at 3:21 PM, Guy Harris via tcpdump-workers wrote: > So we should either 1) require CMake 3.1 or later or 2) forcibly set > PKG_CONFIG_USE_CMAKE_PREFIX_PATH to YES. For now, my inclination is to do > the latter. That w

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

--- Begin Message --- On Sep 9, 2020, at 9:07 AM, Denis Ovsienko via tcpdump-workers wrote: > The "Found pcap-config" message means that FindPCAP.cmake has not found > libpcap by means of pkg-config, and the lack of the message means the > pkg-config method worked. A few weeks ago Ubuntu 18.04

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

--- Begin Message --- On Jan 7, 2021, at 9:35 AM, Bill Fenner via tcpdump-workers wrote: > These jobs are still failing, but now for a different reason. Part of the problem is that pkg-config wasn't finding the locally-installed libpcap under /tmp, because PKG_CONFIG_PATH wasn't set to point

[tcpdump-workers] So which is cooler - tcpdump on your wrist or tcpdump on your Mac's Touch Bar?

--- Begin Message --- $ curl -s https://opensource.apple.com/source/tcpdump/tcpdump-100/tcpdump.xcodeproj/project.pbxproj.auto.html | egrep SUPPORTED_PLATFORMS SUPPORTED_PLATFORMS = macosx iphoneos appletvos watchos bridgeos;

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

--- Begin Message --- On Jan 3, 2021, at 12:15 PM, Denis Ovsienko via tcpdump-workers wrote: > 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 >

Re: [tcpdump-workers] Performance impact with multiple pcap handlers on Linux

--- Begin Message --- On Dec 22, 2020, at 3:31 PM, Linus Lüssing wrote: > Basically we want to do live measurements of the overhead of the mesh > routing protocol and measure and dissect the layer 2 broadcast traffic. > To measure how much ARP, DHCP, ICMPv6 NS/NA/RS/RA, MDNS, LLDP overhead >

Re: [tcpdump-workers] Performance impact with multiple pcap handlers on Linux

--- Begin Message --- On Dec 22, 2020, at 2:05 PM, Linus Lüssing via tcpdump-workers wrote: > I was experimenting a bit with migrating from the use of > pcap_offline_filter() to pcap_setfilter(). > > I was a bit surprised that installing for instance 500 pcap > handlers What is a "pcap

Re: [tcpdump-workers] [OPSAWG] [pcap-ng-format] draft-gharris-opsawg-pcap.txt --- IANA considerations

--- Begin Message --- On Dec 22, 2020, at 8:36 AM, Michael Richardson wrote: > Guy Harris wrote: > >> And, as per my idea of using 65535 to mean "custom linktype", similar >> to pcapng custom blocks and options, with either: > > I'm happy with this proposal, but isn't it pcapng specific? No

Re: [tcpdump-workers] [pcap-ng-format] draft-gharris-opsawg-pcap.txt --- FCS length description

--- Begin Message --- On Dec 22, 2020, at 1:01 AM, Guy Harris wrote: > They were originally intended for use with some stuff NetBSD was doing (I'd > have to look into the history of the NetBSD code), but I think NetBSD stopped > doing that. The commit message for the change that added the

Re: [tcpdump-workers] [pcap-ng-format] draft-gharris-opsawg-pcap.txt --- FCS length description

--- Begin Message --- On Dec 21, 2020, at 4:31 PM, Michael Richardson wrote: > Hi, I have reworked the document that Guy put into XML describing the *PCAP* > (not NG) format. I found the text for LinkType to be confusing, and > frankly, I think wrong. > > * LinkType (32 bits): an unsigned

Re: [tcpdump-workers] [pcap-ng-format] draft-gharris-opsawg-pcap.txt --- IANA considerations

--- Begin Message --- (Resent, from the correct address this time.) On Dec 21, 2020, at 5:51 PM, Michael Richardson wrote: > The short of it is: > > 1) reserve bits 16:28 of linktype as zero. In pcap files, presumably; you have only bits 0:15 in pcapng IDBs. Note that the registry is for

Re: [tcpdump-workers] pcap_lookupdev returning NULL

--- Begin Message --- On Nov 5, 2020, at 1:04 AM, Vaughan Wickham wrote: > Appreciate all the info that you have provided. > > Although it probably doesn't look like it from my questions; I did actually > read some tutorials prior to posting my initial question; and none made > reference to

Re: [tcpdump-workers] pcap_lookupdev returning NULL

--- Begin Message --- On Nov 4, 2020, at 10:26 PM, Vaughan Wickham wrote: > In regards to your latest comments regarding > > sudo setcap cap_net_raw,cap_net_admin+eip {your program} > > Are you saying that I need to compile my program and then start the compiled > version with these

Re: [tcpdump-workers] pcap_lookupdev returning NULL

--- Begin Message --- On Nov 4, 2020, at 9:18 PM, Vaughan Wickham wrote: > Version: libpcap version 1.5.3 That's an older version (CentOS, proudly trailing-edge!), and only returns interfaces that the program can open. Capturing on Linux generally requires, at minimum, the CAP_NET_RAW

Re: [tcpdump-workers] pcap_lookupdev returning NULL

--- Begin Message --- What happens if you put printf("Version: %s\n", pcap_lib_version()); before the pcap_lookupdev() call? It won't fix the pcap_lookupdev() call not to return NULL, but it'll indicate what version of libpcap your program is using, which might help determine what the

Re: [tcpdump-workers] [RFC] Addition of link-layer header types for PCI, PCI-X, and PCI-Express

--- Begin Message --- On Oct 21, 2020, at 1:56 PM, Aki Van Ness via tcpdump-workers wrote: > I'm working on a project that plans to store PCI and PCI-Express > packets in the pcapng format as that's the most appropriate storage > format and I really rather not roll something custom. > > As

Re: [tcpdump-workers] [pcap-ng-format] New Version Notification for draft-tuexen-opsawg-pcapng-02.txt

--- Begin Message --- On Oct 18, 2020, at 1:32 AM, Michael Tuexen wrote: > Just a note. I'm using the .xml format and put a link in the README.md, which > shows the .txt or .html file based on the current .xml. Yes, that's what we were doing for the pcapng draft before switching to

Re: [tcpdump-workers] [pcap-ng-format] New Version Notification for draft-tuexen-opsawg-pcapng-02.txt

--- Begin Message --- On Oct 17, 2020, at 6:01 PM, Michael Richardson wrote: > Guy Harris via tcpdump-workers wrote: > >> So is there anything we do to arrange that the "Current committed >> version as ..." links on the GitHub repository home page work again? &g

Re: [tcpdump-workers] [pcap-ng-format] New Version Notification for draft-tuexen-opsawg-pcapng-02.txt

--- Begin Message --- On Oct 17, 2020, at 4:19 PM, Guy Harris wrote: > Or is there some site that will run kramdown-rfc2629 on a Markdown file and > run xml2rfc on the result, along the lines of what xml2rfc.tools.ietf.org > does? I haven't gotten > >

Re: [tcpdump-workers] [pcap-ng-format] New Version Notification for draft-tuexen-opsawg-pcapng-02.txt

--- Begin Message --- On Sep 28, 2020, at 4:28 PM, Michael Richardson wrote: > Guy Harris wrote: >> For 2), I note that > >> >> https://github.com/pcapng/pcapng/blob/master/draft-tuexen-opsawg-pcapng.md > >> has a bunch of stuff that GitHub isn't treating as markup, such as the >> stuff

Re: [tcpdump-workers] libpcap error codes?

--- Begin Message --- On Oct 7, 2020, at 3:16 PM, Denis Ovsienko via tcpdump-workers wrote: > Do you mean to introduce a function like pcap_error(), which the > developers would be able to interrogate if they need in use cases like > this? Then existing functions could be slowly updated as

Re: [tcpdump-workers] libpcap error codes?

--- Begin Message --- On Oct 7, 2020, at 1:30 PM, Fernando Gont via tcpdump-workers wrote: > WHile using pcap_inject() in Linux, it is failing with "pcap_inject(): send: > Resource temporarily unavailable". In principle, one would expect that for > temporary problems (such as this one), one

  1   2   >