[tcpdump-workers] Re: Setting BPF_SPECIAL_VLAN_HANDLING on a "dead" handle

On Jul 8, 2025, at 7:58 AM, Denis Ovsienko wrote: > On Mon, 7 Jul 2025 13:26:25 -0700 > Guy Harris wrote: > >> There could probably be a bunch of optimizations done to programs in >> that IR. > > The parse tree, as a means of data handover between layers, wou

[tcpdump-workers] Re: Setting BPF_SPECIAL_VLAN_HANDLING on a "dead" handle

On Jul 8, 2025, at 7:36 AM, Denis Ovsienko wrote: > The need to have a pcap_t at all times is very similar to using file > descriptors or sockets: first you obtain a descriptor, then you > initialise it in various ways as necessary, then you have a very small > number of methods to read and to wr

[tcpdump-workers] Re: Setting BPF_SPECIAL_VLAN_HANDLING on a "dead" handle

On Jul 7, 2025, at 6:42 AM, Denis Ovsienko wrote: > One thing that can complicate this is that some always-true and > always-false components are in fact specific to the link-layer type, > for example, "ip" generates: > * always-true for DLT_IPV4 > * always-false for DLT_IPV6 > * a load and a com

[tcpdump-workers] Re: Setting BPF_SPECIAL_VLAN_HANDLING on a "dead" handle

On Jul 7, 2025, at 3:29 AM, Denis Ovsienko wrote: > Yes, and that version could be the same old pcap_compile() if the > pcap_t contained the compilation style requests, as it already contains > the link-layer type and the snapshot. But that still requires pcap_open_dead(), which is somewhat of a

[tcpdump-workers] Re: Setting BPF_SPECIAL_VLAN_HANDLING on a "dead" handle

On Jul 4, 2025, at 2:36 PM, Michael Richardson wrote: > In general, it seems to me like we ought to specify some kind of target BPF > processor option. As you say, pcap mostly just adapts itself to the current > kernel, and the dead version has no options. Currently, the possible backends are:

[tcpdump-workers] Re: Setting BPF_SPECIAL_VLAN_HANDLING on a "dead" handle

On Jul 4, 2025, at 8:55 AM, Bill Fenner wrote: > We may know that we will be using this code on a kernel that > requires BPF_SPECIAL_VLAN_HANDLING, and so I'd like to be able to set that > flag on a "dead" handle. Obviously, the current mechanism is to test this > dynamically when the handle is

[tcpdump-workers] Re: v4/v6 packet length printing inconsistency

On Jun 30, 2025, at 8:43 AM, Guy Harris wrote: >> Perhaps we should implement that flag. > > ...and, if we do, and we split the lines in verbose mode for IPv6, the > -g/--ip-oneline flag would apply both to IPv4 and IPv6. If we implement the flag in the next 4.99.x release, t

[tcpdump-workers] Re: v4/v6 packet length printing inconsistency

On Jun 30, 2025, at 7:46 AM, Denis Ovsienko wrote: > 1: https://github.com/the-tcpdump-group/tcpdump/issues/810 To quote a comment I added to that issue: >> Personally, I'd prefer a single line of output for easy parsing. > > > At one point, so did Apple, so they added a `-g` ("g" for "greppa

[tcpdump-workers] Re: bringing in distro and embedded patches

On Jun 23, 2025, at 6:32 AM, Denis Ovsienko wrote: > Also there are forks of tcpdump and libpcap in the base system > part of the major BSDs, some of these have diverged very substantially. FreeBSD's is a fork that appear to get synced with each of our releases, so it hasn't diverged much. It's

[tcpdump-workers] Re: tcpdump and pcapng with comments

On Apr 8, 2025, at 7:13 AM, Mahesh V wrote: > I dont have that information. > Question remains, why does flex choose m4 binary that is compiled into it and > not from the PATH (env variable) > which m4 and which flex (both exist in the same path) That's a good question. I do not know the answ

[tcpdump-workers] Re: tcpdump and pcapng with comments

On Apr 7, 2025, at 2:11 AM, Mahesh V wrote: > Flex is not getting built. We have the binary checked in to our repository. What process produced that binary? Is it a binary you compiled, is it a copy of a binary from the OS, or is it from somewhere else? _

[tcpdump-workers] Re: tcpdump and pcapng with comments

On Apr 6, 2025, at 11:19 PM, Mahesh V wrote: > configure:7921: checking for flex > configure:7937: found tools/arm-5.3-uclibc-1.0.12/usr/bin/flex > configure:7948: result: flex > configure:7986: flex conftest.l > flex: fatal internal error, exec of > /var/tmp/tool-chains/buildroot-2016.02-5.3-ar

[tcpdump-workers] Re: tcpdump and pcapng with comments

On Apr 6, 2025, at 2:28 PM, Michael Richardson wrote: > Mahesh V wrote: >> I added some code (modified) tcpdump to write the pcapng file. >> while configuring/compiling the source code I get this error >> This is a cross compilation for ARM platform > > Well, likely the resulting flex test can'

[tcpdump-workers] Re: tcpdump and pcapng with comments

On Apr 4, 2025, at 11:29 AM, Michael Richardson wrote: > I can't recall if we can read pcapng. libpcap - and thus programs, such as tcpdump, that use libpcap to read capture files - can read some pcapng files, as long as the current libpcap API can handle them. That's been the case since libp

[tcpdump-workers] Re: tcpdump and pcapng with comments

On Apr 4, 2025, at 10:22 AM, Mahesh V wrote: > I would like to know if > 1) tcpdump can write pcapng format (instead of just pcap) Currently, no. tcpdump uses libpcap to read and write capture files, and libpcap doesn't yet support writing pcapng. > 2) Accept per packet comments from the kern

[tcpdump-workers] Re: bpf_dump.c

On Feb 12, 2025, at 11:05 PM, Guy Harris wrote: > Given that BDEBUG is a libpcap definition that affects a lot more things, my > inclination would be to, if we keep tcpdump's bpf_dump.c, remove the BDEBUG > stuff ...which Denis has done. _

[tcpdump-workers] Re: bpf_dump.c

On Feb 12, 2025, at 1:54 PM, Francois-Xavier Le Bail via tcpdump-workers wrote: > They are also different: > > $ diff bpf_dump.c ../libpcap/bpf_dump.c > > 24,25c24 > < #include "netdissect-stdinc.h" > < > --- > > #include That's because the first one

[tcpdump-workers] Re: Returned mail: Data format error

On Nov 18, 2024, at 9:08 AM, Michael Richardson wrote: > The message about the spam was in fact spam. So what is the purpose of those types of spam? Testing a list's spam detectors? ___ tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org

[tcpdump-workers] Re: capture and inject device capabilities in libpcap

On Nov 18, 2024, at 12:15 PM, Michael Richardson wrote: > Denis Ovsienko wrote: >> One complication here is that in some cases libpcap may not be aware of >> a device capability until it gets an error from the OS (as is the case >> with PCAP_ERROR_CAPTURE_NOTSUP in pcap-linux.c), so pcap_findall

[tcpdump-workers] Re: capture and inject device capabilities in libpcap

On Nov 18, 2024, at 11:54 AM, Denis Ovsienko wrote: > The current approach in libpcap is such that an application at some > point tries to activate a device, and if the device does not support > capturing packets, pcap_activate() fails with the > PCAP_ERROR_CAPTURE_NOTSUP error code. One drawbac

[tcpdump-workers] Re: Returned mail: Data format error

Bogus - the oldest Received: line is Received: from wireshark.org (unknown [64.124.12.162]) by rivoli.gatineau.credil.org (Postfix) with ESMTP id 7C05A9EC for ; Sun, 17 Nov 2024 14:39:06 -0500 (EST) and $ host 64.124.12.162 162.12.124.64.in-addr.a

[tcpdump-workers] Re: Flush OS buffer before termination

On Oct 20, 2024, at 2:57 AM, Garri Djavadyan wrote: >>> I have to use a very big buffer with a very slow storage, much >>> slower >>> than the rate of coming packets received by the filter, and it is >>> preferred not to lose a single packet after initiating termination >>> the >>> process. >> >

[tcpdump-workers] Re: Flush OS buffer before termination

> On Oct 20, 2024, at 12:11 AM, Garri Djavadyan wrote: > > On Sat, 2024-10-19 at 23:58 -0700, Guy Harris wrote: >> On Oct 19, 2024, at 5:01 PM, Garri Djavadyan >> wrote: >> >>> I am looking for a way to force tcpdump flush Linux OS buffer >>> b

[tcpdump-workers] Re: Flush OS buffer before termination

On Oct 19, 2024, at 5:01 PM, Garri Djavadyan wrote: > I am looking for a way to force tcpdump flush Linux OS buffer before > terminating. I have checked the man page and the mailing list archives > but did not manage to find anything related. > > When I terminate tcpdump process with SIGINT or S

[tcpdump-workers] Re: IP Address Anonymization Feature in tcpdump

On Jun 10, 2024, at 12:39 PM, Alberto Perez Bogantes via tcpdump-workers wrote: > We've been working on adding a new feature to tcpdump that will allow IP > address anonymization ... ... > > I am sharing my GitHub project (https://github.com/aperezb21/tcpdump), > which is forked from commit b

[tcpdump-workers] Re: Assistance with Capturing cURL Request using tcpdump

On Oct 1, 2024, at 8:38 AM, Kaushal Shriyan wrote: > Thanks, Michael, for the quick response. Is there a way to capture and > analyze *HTTPS* traffic since the data is encrypted? Maybe, *if* you can get the necessary information; see https://wiki.wireshark.org/TLS#tls-decryption As it

[tcpdump-workers] tcpdump -i - not just for Windows any more!

ubu22-04$ cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=22.04 DISTRIB_CODENAME=jammy DISTRIB_DESCRIPTION="Ubuntu 22.04.5 LTS" ubu22-04$ ifconfig -a ens33: flags=4163 mtu 1500 inet 172.16.135.246 netmask 255.255.255.0 broadcast 172.16.135.255 inet6 fe80::eee8:133e:43dd:47

[tcpdump-workers] Re: AF_INET6 values

obvious issue caused by 1), two issues caused by 2) also appeared, one of which occurred with *BSD (including CupertinoBSD, a/k/a Darwin) servers, and another of which occurred only between Solaris and non-Solaris platforms. The fix for these issues was commit 6ee13e223c9709e79ac112f8c37ff0a72

[tcpdump-workers] Re: Support for saving pcapng

On May 20, 2024, at 9:56 AM, Michael Richardson wrote: >> implementation under the APSL license, I wonder if the community is >> allowed to submit a pull request for it. Are there any restrictions or >> guidelines we should be aware of in this regard? Thanks for your time >> and patience. > > M

[tcpdump-workers] Re: Support for saving pcapng

On May 20, 2024, at 8:31 AM, luoyuxuan.c...@gmail.com wrote: >I've noticed that the question about libpcap's support for writing files > in the pcapng format has been brought up multiple times in the mailing list. > Yet, I'm still curious about the current status of this function. Can anyone

[tcpdump-workers] Re: Dropping support in tcpdump for older versions of libpcap?

On Apr 12, 2024, at 6:49 PM, Guy Harris wrote: > Is there any reason not to require libpcap 1.0 or later? If there is, is > there any reason not to require libpcap 0.7 or later? OK, support removed, in the main branch. for libpcaps with only pre-1.0 APIs. The 4.99 branch still support

[tcpdump-workers] Re: pcap-savefile(5) in libpcap-1.10

On May 10, 2024, at 1:39 PM, Denis Ovsienko wrote: > I have been looking through commits and the 1.10.5 section of libpcap > change log, and the recent changes to the link-layer header type field > structure look like a potential place for things to go wrong. > > Specifically, the new prose says

[tcpdump-workers] Re: Question about an uninitialized array in bpf_filter

On Apr 29, 2024, at 7:19 AM, Michal Ruprich wrote: > I was wondering, whether the mem[BPF_MEMWORDS] array in function > pcapint_filter_with_aux_data in bpf_filter.c should be initialized? If the > switch hits cases BPF_LD|BPF_MEM or BPF_LDX|BPF_MEM the variables A or X are > filled with random

[tcpdump-workers] Re: Dropping support in tcpdump for older versions of libpcap?

On Apr 19, 2024, at 5:49 AM, Denis Ovsienko wrote: > On Fri, 12 Apr 2024 18:49:05 -0700 > Guy Harris wrote: ... > Since tcpdump is the reference implementation of a program that uses > libpcap, it may be a good occasion to improve the solution space such > that other so

[tcpdump-workers] Re: RadioTap Parsing as seperate library

On Apr 15, 2024, at 3:47 PM, Ravi chandra wrote: > I am planning to create an ieee 802.11 packet RadioTap parsing > code/library [offlines processing of pcap-ng files. Decoding each and > every field and write it to a .csv file]. If that's all you're doing, is there some reason why you don't jus

[tcpdump-workers] Dropping support in tcpdump for older versions of libpcap?

A while ago, tcpdump and its configuration script were modified - mainly by Bill Fenner, as I remember - so that it didn't require a contemporary version of libpcap, and could be built with older versions of libpcap. The intent, as I remember, was to allow somebody who was using a system that p

[tcpdump-workers] Re: openwrt Conclusions from CVE-2024-3094 (libxz disaster)

On Apr 1, 2024, at 6:53 AM, Michael Richardson wrote: > I wonder if we should nuke our own make tarball system. I.e., replace: to get {libpcap,tcpdump,tcpslice} version X.Y.Z, download {libpcap,tcpdump,tcpslice}-X.Y.Z.tar.{compression-suffix} with to get {libpcap,tcpdump,tcps

[tcpdump-workers] Re: SIGINFO/SIGUSR1 and SIGUSR2

On Mar 28, 2024, at 2:19 PM, Denis Ovsienko wrote: > Yes, AIX and Haiku sometimes make portability issues manifest. And, in this case, Solaris doesn't have SIGINFO, either; SunOS 0.x-4.x didn't have it, as BSD hadn't picked it up, and they didn't pass it along to be put into SVR4, so it's not

[tcpdump-workers] Re: SIGINFO/SIGUSR1 and SIGUSR2

On Mar 28, 2024, at 3:01 AM, Denis Ovsienko wrote: > There is a rather old pull request at [1], which was supposed to make > use of the then-unused SIGUSR2, but whilst it was waiting, another pull > request used the signal for another code path. > > There is a potential way to manage this kind o

[tcpdump-workers] Re: HP-UX support and portability

On Mar 12, 2024, at 2:07 PM, Rick Jones via tcpdump-workers wrote: > If https://en.wikipedia.org/wiki/HP-UX#Version_history is any indication, > there are ~21 months left on HP's (er, sorry, HPE's) own support for HP-UX. As far as I know, now that Itania are no longer being manufactured and shi

[tcpdump-workers] Re: Sharing code between print-icmp.c and print-icmp6.c

On Feb 5, 2024, at 9:38 AM, Bill Fenner wrote: > Is this a reasonable way to proceed? Yes. Perhaps have a file icmp-common.c or print-icmp-common.c with code and data structures common to ICMP(v4) and ICMPv6? ___ tcpdump-workers mailing list -- tcpdu

[tcpdump-workers] Test

Is the list working? ___ tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org To unsubscribe send an email to tcpdump-workers-le...@lists.tcpdump.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

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

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 in the footer structure

[tcpdump-workers] Removing untested libpcap support for older platforms

The MS-DOS support in libpcap was recently removed in the main branch; the comment for the pull request is "MSDOS packet driver interface is no longer testable", and the comment for the first commit is "MSDOS packet driver interface is no longer testable, anyone needs it can use a previous versi

[tcpdump-workers] Test 2

Another test of subscribing via the Web ___ tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org To unsubscribe send an email to tcpdump-workers-le...@lists.tcpdump.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[tcpdump-workers] This is a test - ignore

Testing to see whether subscribing worked. ___ tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org To unsubscribe send an email to tcpdump-workers-le...@lists.tcpdump.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[tcpdump-workers] Re: libpcap : An entry in the manual about multithreading

On May 7, 2023, at 9:27 AM, Michael Richardson wrote: > Frederick Virchanza Gotham wrote: >> I think that there should be a page in the libpcap manual that >> explicitly explains the multithreading capabilities and limitations. > > okay, that sounds reasonable. > git clone https://github.com/t

[tcpdump-workers] Re: Pcap debug at runtime

On Feb 20, 2023, at 12:15 PM, Paschal Chukwuebuk Amusuo wrote: > Please, is there a way to print out debug statements at runtime when using > pcap? Debug statements in your program? Add printf() or fprintf(stderr, ...) or... calls to your program. Debug statements in libpcap? Get the libpc

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

On Feb 20, 2023, at 2:20 AM, Guy Harris wrote: > So the code is correct, but could easily be misintrpreted. Perhaps it'd be > better if we used the values from af.h rather than using AF_INET and > AF_INET6. Done in 0dc32a024773968cb1ae00729758e61b7418564a I'll see wh

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

On Feb 20, 2023, at 12:17 AM, Denis Ovsienko wrote: > AF_INET6 looks a bit more convoluted. There is some code that uses > AF_INET6 to dissect wire encoding, which is usually a wrong idea. For > example, pimv2_addr_print() switches on AF_INET and AF_INET6, and the > PIMv2 header encoding (RFC 4

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

On Feb 18, 2023, at 10:27 AM, Denis Ovsienko wrote: > OS IPv6 support would be a very reasonable requirement for tcpdump 5. Which would, among other things, let us remove the tests for various add-on IPv6 stacks in configure.ac. ___ tcpdump-workers ma

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

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

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

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

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

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 f

Re: [tcpdump-workers] upcoming tcpslice release

read -lsystemd ' Fixed in commit 588f0bb996230a84a8cf10ddf30cc514e3ba5a68 (HEAD -> master, origin/master, origin/HEAD) Author: Guy Harris Date: Sat Oct 15 15:18:13 2022 -0700 configure: use pcap-config --static-pcap-only if available. If we're linking with a libpcap in ../libpcap*, it's static, bu

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 pa

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

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

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

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

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

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

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 sectio

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 topo

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

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

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

  1   2   3   4   5   6   7   8   9   10   >