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

[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

[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

[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

[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

[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

[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

[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

[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

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

[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

[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

[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

[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

[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 whether anyt

[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

[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

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

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

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

Re: [tcpdump-workers] upcoming tcpslice release

-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, but we only need t

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 >>> 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?&quo

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

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 lea

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

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

  1   2   3   4   5   6   7   8   9   10   >