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

2022-01-06 Thread Guy Harris via tcpdump-workers
--- 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?

2022-01-06 Thread Guy Harris via tcpdump-workers
--- 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?

2022-01-06 Thread Guy Harris via tcpdump-workers
--- 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

2022-01-06 Thread Guy Harris via tcpdump-workers
--- 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

2022-01-05 Thread Guy Harris via tcpdump-workers
--- 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 ?

2021-12-06 Thread Guy Harris via tcpdump-workers
--- 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

2021-08-11 Thread Guy Harris via tcpdump-workers
--- 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

2021-08-08 Thread Guy Harris via tcpdump-workers
--- 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

2021-08-08 Thread Guy Harris via tcpdump-workers
--- 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

2021-08-03 Thread Guy Harris via tcpdump-workers
--- 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

2021-08-02 Thread Guy Harris via tcpdump-workers
--- 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

2021-08-01 Thread Guy Harris via tcpdump-workers
--- 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

2021-08-01 Thread Guy Harris via tcpdump-workers
--- 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

2021-07-31 Thread Guy Harris via tcpdump-workers
--- 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

2021-07-24 Thread Guy Harris via tcpdump-workers
--- 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

2021-04-22 Thread Guy Harris via tcpdump-workers
--- 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

2021-03-24 Thread Guy Harris via tcpdump-workers
--- 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)

2021-03-23 Thread Guy Harris via tcpdump-workers
--- 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

2021-03-22 Thread Guy Harris via tcpdump-workers
--- 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

2021-03-18 Thread Guy Harris via tcpdump-workers
--- 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

2021-03-12 Thread Guy Harris via tcpdump-workers
--- 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

2021-03-12 Thread Guy Harris via tcpdump-workers
--- 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

2021-03-04 Thread Guy Harris via tcpdump-workers
--- 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

2021-03-03 Thread Guy Harris via tcpdump-workers
--- 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

2021-02-04 Thread Guy Harris via tcpdump-workers
--- 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

2021-02-03 Thread Guy Harris via tcpdump-workers
--- 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

2021-01-27 Thread Guy Harris via tcpdump-workers
--- 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

2021-01-24 Thread Guy Harris via tcpdump-workers
--- 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

2021-01-23 Thread Guy Harris via tcpdump-workers
--- 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?

2021-01-22 Thread Guy Harris via tcpdump-workers
--- 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

2021-01-22 Thread Guy Harris via tcpdump-workers
--- 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?

2021-01-18 Thread Guy Harris via tcpdump-workers
--- 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

2021-01-08 Thread Guy Harris via tcpdump-workers
--- 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

2021-01-07 Thread Guy Harris via tcpdump-workers
--- 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

2021-01-07 Thread Guy Harris via tcpdump-workers
--- 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

2021-01-07 Thread Guy Harris via tcpdump-workers
--- 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?

2021-01-05 Thread Guy Harris via tcpdump-workers
--- 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

2021-01-03 Thread Guy Harris via tcpdump-workers
--- 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

2020-12-22 Thread Guy Harris via tcpdump-workers
--- 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

2020-12-22 Thread Guy Harris via tcpdump-workers
--- 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

2020-12-22 Thread Guy Harris via tcpdump-workers
--- 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 prop

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

2020-12-22 Thread Guy Harris via tcpdump-workers
--- 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 t

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

2020-12-22 Thread Guy Harris via tcpdump-workers
--- 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

2020-12-21 Thread Guy Harris via tcpdump-workers
--- 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

2020-11-05 Thread Guy Harris via tcpdump-workers
--- 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

2020-11-04 Thread Guy Harris via tcpdump-workers
--- 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

2020-11-04 Thread Guy Harris via tcpdump-workers
--- 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

2020-11-04 Thread Guy Harris via tcpdump-workers
--- 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

2020-10-25 Thread Guy Harris via tcpdump-workers
--- 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

2020-10-18 Thread Guy Harris via tcpdump-workers
--- 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

2020-10-17 Thread Guy Harris via tcpdump-workers
--- 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

2020-10-17 Thread Guy Harris via tcpdump-workers
--- 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 > > https://xml2rfc

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

2020-10-17 Thread Guy Harris via tcpdump-workers
--- 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 treatin

Re: [tcpdump-workers] libpcap error codes?

2020-10-07 Thread Guy Harris via tcpdump-workers
--- 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?

2020-10-07 Thread Guy Harris via tcpdump-workers
--- 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

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

2020-09-30 Thread Guy Harris via tcpdump-workers
--- Begin Message --- On Sep 29, 2020, at 7:14 PM, Qin Wu wrote: > Can you clarify what functionalities is missed for more modern applications? > Since it is enhancement to libpcap, do you expect all the future packet > capture tools support the format defined in this draft? pcapng is a file

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

2020-09-28 Thread Guy Harris via tcpdump-workers
--- Begin Message --- On Sep 28, 2020, at 2:00 PM, Michael Tuexen wrote: > On 28. Sep 2020, at 22:48, Guy Harris wrote: > >> On Sep 28, 2020, at 1:42 PM, Michael Tuexen wrote: >> >>> Shouldn't we write up (I can work on an initial version) of &g

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

2020-09-28 Thread Guy Harris via tcpdump-workers
--- Begin Message --- On Sep 28, 2020, at 1:42 PM, Michael Tuexen wrote: > Shouldn't we write up (I can work on an initial version) of > a specification for .pcap. https://github.com/pcapng/pcapng/blob/master/draft-gharris-opsawg-pcap.xml

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

2020-09-28 Thread Guy Harris via tcpdump-workers
--- Begin Message --- On Sep 28, 2020, at 12:06 PM, Michael Tuexen wrote: > On 28. Sep 2020, at 20:26, Michael Richardson wrote: > >> internet-dra...@ietf.org wrote: >>> Diff: >>> https://www.ietf.org/rfcdiff?url2=draft-tuexen-opsawg-pcapng-02 >> >> Hi, I have converted the xml to markdown. >

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

2020-09-28 Thread Guy Harris via tcpdump-workers
--- Begin Message --- On Sep 28, 2020, at 12:06 PM, Michael Tuexen wrote: > Do we want to finally publish that? Up to now, I think the point was to > find a home where it is substantially discussed and improved... For example, unlike pcap, which is not easily changeable (you *can* change it,

Re: [tcpdump-workers] tcpdump ack why become more 6 bytes

2020-09-14 Thread Guy Harris via tcpdump-workers
--- Begin Message --- This is not a security issue; questions about tcpdump should be sent to tcpdump-workers@lists.tcpdump.org, which is where I'm sending this question. On Sep 14, 2020, at 8:22 PM, Accepted <532876...@qq.com> wrote: > hi, in this picture, I try to use tcpdump to get package

Re: [tcpdump-workers] backward compatibility in pcap_loop(3PCAP)?

2020-08-21 Thread Guy Harris via tcpdump-workers
--- Begin Message --- On Aug 21, 2020, at 2:48 PM, Denis Ovsienko via tcpdump-workers wrote: > The man page says: > > (In older versions of libpcap, the behavior when cnt was 0 > was undefined; different platforms and devices behaved > differently, so code that must

Re: [tcpdump-workers] Using libnetdissect in other code, outside tcpdump source tree

2020-08-12 Thread Guy Harris via tcpdump-workers
--- Begin Message --- On Aug 12, 2020, at 1:31 PM, Guy Harris via tcpdump-workers wrote: > We should probably have an include/libnetdissect directory in which we > install netdissect.h and the headers it requires. Or include/netdissect. > However, API-declaring headers should *NEVER

Re: [tcpdump-workers] Using libnetdissect in other code, outside tcpdump source tree

2020-08-12 Thread Guy Harris via tcpdump-workers
--- Begin Message --- On Aug 11, 2020, at 4:55 AM, Bill Fenner via tcpdump-workers wrote: > Is there a plan for a public face for libnetdissect? At some point we should probably do that. (Back in the late '90's, I discovered a program called tcpview, which was a Motif(!)-based GUI network

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

2020-08-12 Thread Guy Harris via tcpdump-workers
--- Begin Message --- (Your first attempt seems to have worked - finally. Perhaps Michael cleared the backlog?) On Aug 10, 2020, at 4:24 AM, Denis Ovsienko via tcpdump-workers wrote: > It turns out, pcap_compile_nopcap() has been a part of the libpcap API > since version 0.5 (June 2000), but

[tcpdump-workers] About DLT_LANE8023 and lane_if_print()

2020-08-12 Thread Guy Harris via tcpdump-workers
--- Begin Message --- On Aug 4, 2020, at 1:28 PM, Francois-Xavier Le Bail wrote: > lane_if_print() in print-lane.c > (Added by 77b2a4405561467f66a3dfb0f8ce2b0eaa5ebaf9 in Sun Nov 21 1999 "print > of ATM LanEmulation") > is called for DLT_LANE8023: > > print.c-56-#ifdef DLT_LANE8023 >

Re: [tcpdump-workers] tcpslice licence

2020-08-03 Thread Guy Harris via tcpdump-workers
--- Begin Message --- On Aug 3, 2020, at 12:33 PM, Denis Ovsienko via tcpdump-workers wrote: > > Whilst updating the description of files in tcpslice (the little > relative of tcpdump) repository, it came to my attention that it does > not have the customary LICENSE file. I have looked through

Re: [tcpdump-workers] Proposed update to DLT_BLUETOOTH_LE_LL_WITH_PHDR

2020-07-13 Thread Guy Harris via tcpdump-workers
--- Begin Message --- On Jul 13, 2020, at 8:09 AM, Sultan Khan wrote: > Hmm. Chris Kilgour (whiterocker) originally created the spec, and the version > on tcpdump.org was just a backup copy. Now, Chris has said that he is no > longer active in the Bluetooth LE sniffing space, and he doesn’t

Re: [tcpdump-workers] Proposed update to DLT_BLUETOOTH_LE_LL_WITH_PHDR

2020-07-13 Thread Guy Harris via tcpdump-workers
--- Begin Message --- On Jul 13, 2020, at 9:02 AM, Sultan Khan wrote: > Thanks Chris. I’ll make a pull request to tcpdump-htdocs later today, and > I’ll include a link to the previous version of the spec as an archive.org > link to the old one on whiterocker.com. The new version is a superset

Re: [tcpdump-workers] Proposed update to DLT_BLUETOOTH_LE_LL_WITH_PHDR

2020-07-13 Thread Guy Harris via tcpdump-workers
--- Begin Message --- On Jul 10, 2020, at 2:57 PM, Sultan Khan wrote: > Link to the updated version of the spec with the latest changes: >

Re: [tcpdump-workers] Proposed update to DLT_BLUETOOTH_LE_LL_WITH_PHDR

2020-07-10 Thread Guy Harris via tcpdump-workers
--- Begin Message --- For an advertising physical channel PDU, it appears that the PDU type is in the least-significant 4 bits of the PDU header. Is that not present in an auxiliary advertising packet?--- End Message --- ___ tcpdump-workers mailing

Re: [tcpdump-workers] Proposed update to DLT_BLUETOOTH_LE_LL_WITH_PHDR

2020-07-10 Thread Guy Harris via tcpdump-workers
--- Begin Message --- A couple more editorial comments: In the description of the bits in the Flags field, I'd describe the 0x3000 bits as "PDU type dependent", and, after they're listed indicate that: For PDU types other than type 1 (auxiliary advertising), the PDU type dependent

Re: [tcpdump-workers] Proposed update to DLT_BLUETOOTH_LE_LL_WITH_PHDR

2020-07-09 Thread Guy Harris via tcpdump-workers
--- Begin Message --- On Jul 9, 2020, at 1:46 PM, Sultan Khan wrote: > Through discussions with Joakim Anderson (of Nordic) and Mike Ryan (Ubertooth > developer), and going through several iterations of proposed protocol > updates, I/we came up with this: >

[tcpdump-workers] Reading capture files with an unknown link-layer header type

2020-06-11 Thread Guy Harris via tcpdump-workers
--- Begin Message --- François checked in a change to tcpdump so that, if it's handed a capture file with a link-layer header type for which it has no dissector, it just dumps the packet data in hex, rather than failing with an indication that the header type isn't supported. However,

Re: [tcpdump-workers] [AiG-CERT #104737] DLT value

2020-06-11 Thread Guy Harris via tcpdump-workers
--- Begin Message --- On Jun 2, 2020, at 12:58 AM, Airbus CERT via tcpdump-workers wrote: > The layout is > https://docs.microsoft.com/en-us/windows/win32/api/evntcons/ns-evntcons-event_header So each packet's data starts with, in order: a 2-octet event record size; a 2-octet

Re: [tcpdump-workers] [tcpdump] Keep win32/prj/WinDump.dsp ?

2020-06-08 Thread Guy Harris via tcpdump-workers
--- Begin Message --- On Jun 8, 2020, at 12:24 PM, Francois-Xavier Le Bail wrote: > Thus all the files in win32/prj/ could be removed? > (WinDump.dsp WinDump.dsw WinDump.sln WinDump.vcproj) I have no problem removing them and requiring Windows users to ue CMake, especially given that newer

Re: [tcpdump-workers] [AiG-CERT #104737] DLT value

2020-06-02 Thread Guy Harris via tcpdump-workers
--- Begin Message --- On Jun 2, 2020, at 12:22 AM, Airbus CERT via tcpdump-workers wrote: > Yes exactly each packet is an event. The layout of the event is > https://docs.microsoft.com/en-us/windows/win32/api/evntcons/ns-evntcons-event_header > and >

Re: [tcpdump-workers] [AiG-CERT #104737] DLT value

2020-05-29 Thread Guy Harris via tcpdump-workers
--- Begin Message --- On May 29, 2020, at 3:23 AM, Airbus CERT via tcpdump-workers wrote: > I would like to request you to get a DTL value for the PR > https://github.com/the-tcpdump-group/libpcap/pull/934. > This PR intend to add ETW capture for libpcap. So is each packet an Event Tracing

Re: [tcpdump-workers] [tcpdump] Keep win32/prj/WinDump.dsp ?

2020-05-24 Thread Guy Harris via tcpdump-workers
--- Begin Message --- On May 24, 2020, at 4:37 AM, Francois-Xavier Le Bail via tcpdump-workers wrote: > 15 printers are missing in win32/prj/WinDump.dsp. > Does anyone use it? Any reason to keep it ? Note that the *supported* way to build tcpdump (and libpcap) on Windows is with CMake (which

Re: [tcpdump-workers] Compile libpcap with DLT_LINUX_SLL2

2020-05-09 Thread Guy Harris via tcpdump-workers
--- Begin Message --- BTW, having just implemented SLL2 support in Wireshark, the layout of the header really doesn't work as well as I'd like with ARPHRD_NETLINK packets. I'd prefer something like struct header { uint16_t hatype;/* link-layer address type */

Re: [tcpdump-workers] LINUX_SLL2 printing update

2020-05-08 Thread Guy Harris via tcpdump-workers
--- Begin Message --- On May 8, 2020, at 9:57 PM, Francois-Xavier Le Bail via tcpdump-workers wrote: > For a quick look, I don't need 'ifindex N', but I need 'In/Out,...' > > Thus I propose to print: +1 --- End Message --- ___ tcpdump-workers

Re: [tcpdump-workers] Compile libpcap with DLT_LINUX_SLL2

2020-05-08 Thread Guy Harris via tcpdump-workers
--- Begin Message --- On May 8, 2020, at 10:47 AM, Guy Harris via tcpdump-workers wrote: > No, nobody appears to have contributed a change to add support to > epan/dissectors/packet-sll.c yet. I just did; it was a significant enough change to a bit of infrastructure used by other diss

Re: [tcpdump-workers] Compile libpcap with DLT_LINUX_SLL2

2020-05-08 Thread Guy Harris via tcpdump-workers
--- Begin Message --- On Mar 31, 2020, at 2:10 AM, Francois-Xavier Le Bail wrote: > To avoid breaking program that cannot use SLL2, Note, by the way, that one program that can't dissect LINKTYPE_LINUX_SLL2 packets is named "Wireshark". No, nobody appears to have contributed a change to add

Re: [tcpdump-workers] Compile libpcap with DLT_LINUX_SLL2

2020-05-08 Thread Guy Harris via tcpdump-workers
--- Begin Message --- On Mar 31, 2020, at 2:10 AM, Francois-Xavier Le Bail wrote: > On 31/03/2020 00:04, Petr Vorel wrote: >> Hi Guy, >> BTW man pages (pcap.3pcap.in, pcap_datalink.3pcap.in, pcap_loop.3pcap and pcap_next_ex.3pcap) mention only DLT_LINUX_SLL. >> >>> Fixed in commit

Re: [tcpdump-workers] decode MPLS-contained packets?

2020-05-07 Thread Guy Harris via tcpdump-workers
--- Begin Message --- On May 5, 2020, at 1:01 PM, Francois-Xavier Le Bail via tcpdump-workers wrote: > Wireshark MPLS heuristic is not perfect and has been criticized but is still > there :-) hopefully > correctly parsing your data as well. *No* heuristic will be perfect here. > For tcpdump

Re: [tcpdump-workers] decode MPLS-contained packets?

2020-05-07 Thread Guy Harris via tcpdump-workers
--- Begin Message --- On May 7, 2020, at 12:04 AM, Francois-Xavier Le Bail via tcpdump-workers wrote: > On 07/05/2020 08:53, Guy Harris via tcpdump-workers wrote: > >> "Looks like a valid Ethernet address" is defined as "the first three octets >> appear in Wir

Re: [tcpdump-workers] decode MPLS-contained packets?

2020-05-07 Thread Guy Harris via tcpdump-workers
--- Begin Message --- On May 5, 2020, at 11:36 AM, Gert Doering via tcpdump-workers wrote: > So, given that the first 16 bits are "4 bit always 0, and 12 bits > reserved-must-be-set-to-0", using these as heuristics for "if two 0-bytes > are following the MPLS headers, it's a control word, so we

Re: [tcpdump-workers] decode MPLS-contained packets?

2020-05-07 Thread Guy Harris via tcpdump-workers
--- Begin Message --- On May 5, 2020, at 3:15 AM, Gert Doering via tcpdump-workers wrote: > tcpdump's print-mpls.c already does "if I know what upper-layer protocol > is in here, I call the appropriate printer". But there is no well-defined > type field, so it fails for my packets, and and

[tcpdump-workers] What's the "link level header" in "minus its link level header" for the -x flag?

2020-04-30 Thread Guy Harris via tcpdump-workers
--- Begin Message --- (Opening this up to the full tcpdump-workers list, to get more user input.) On Apr 30, 2020, at 11:40 AM, Francois-Xavier Le Bail wrote: > The tcpdump manual states: > > -x When parsing and printing, in addition to printing the headers > of each

Re: [tcpdump-workers] Legacy Linux kernel support

2020-04-01 Thread Guy Harris via tcpdump-workers
--- Begin Message --- On Apr 1, 2020, at 4:14 PM, Mario Rugiero via tcpdump-workers wrote: > I haven't yet been able to test it, which is why I've been delaying > writing about this, > but these two commits[0][1], which according to these threads[2][3] > are the ones fixing > the timeout issue,

Re: [tcpdump-workers] New RFCs for 1) pcap file format and 2) rpcapd protocol?

2020-04-01 Thread Guy Harris via tcpdump-workers
--- Begin Message --- On Apr 1, 2020, at 11:51 AM, Michael Richardson wrote: > Guy Harris via tcpdump-workers wrote: >>> >>>> 5) Treat rpcap as "remote procedure call for libpcap" and put it under the >>>> the-tcpdump-group team, and put pcap unde

Re: [tcpdump-workers] New RFCs for 1) pcap file format and 2) rpcapd protocol?

2020-03-31 Thread Guy Harris via tcpdump-workers
--- Begin Message --- On Mar 22, 2020, at 11:40 AM, Francois-Xavier Le Bail wrote: > On 22/03/2020 18:29, Guy Harris via tcpdump-workers wrote: > >> 5) Treat rpcap as "remote procedure call for libpcap" and put it under the >> the-tcpdump-group team, and put pcap

Re: [tcpdump-workers] [tcpdump] About smiInit() parameter

2020-03-30 Thread Guy Harris via tcpdump-workers
--- Begin Message --- > On Mar 30, 2020, at 10:24 AM, Francois-Xavier Le Bail > wrote: > > Hi Guy, > > We have: > $ git grep -n '"tcpdump"' > netdissect.c:72:smiInit("tcpdump"); > > netdissect.c is a part of libnetdissect. > > Should we use > smiInit("libnetdissect"); > or

[tcpdump-workers] "Custom" link-layer types for pcap and pcapng

2020-03-26 Thread Guy Harris via tcpdump-workers
--- Begin Message --- Here's the proposal for "custom" link-layer types I threatened^Wpromised in my earlier email. A link-layer type value of 0x will be reserved as LINKTYPE_CUSTOM, with libpcap offering a DLT_CUSTOM. A custom link-layer type has a 32-bit IANA-registered Private

Re: [tcpdump-workers] New RFCs for 1) pcap file format and 2) rpcapd protocol?

2020-03-26 Thread Guy Harris via tcpdump-workers
--- Begin Message --- On Mar 26, 2020, at 7:10 PM, Guy Harris via tcpdump-workers wrote: > (Note that its purpose is to document the *existing* format, rather than be a > source of proposed changes.) ...proposed changes to the format. I am, however, planning on proposing a mec

Re: [tcpdump-workers] New RFCs for 1) pcap file format and 2) rpcapd protocol?

2020-03-26 Thread Guy Harris via tcpdump-workers
--- Begin Message --- On Mar 22, 2020, at 10:29 AM, Guy Harris via tcpdump-workers wrote: > 5) ... and put pcap under the pcapng team as per the same reason as 4). Done. It's pointed to by https://github.com/pcapng/pcapng and the XML source is at https://github.com/pca

Re: [tcpdump-workers] New RFCs for 1) pcap file format and 2) rpcapd protocol?

2020-03-22 Thread Guy Harris via tcpdump-workers
--- Begin Message --- On Mar 21, 2020, at 2:38 PM, Guy Harris via tcpdump-workers wrote: > On Mar 21, 2020, at 2:14 PM, Guy Harris via tcpdump-workers > wrote: > >> The options I see are: > > 4) add a new team for rpcap, as it's a protocol rather than a file for

Re: [tcpdump-workers] [Wireshark-dev] New RFCs for 1) pcap file format and 2) rpcapd protocol?

2020-03-22 Thread Guy Harris via tcpdump-workers
--- Begin Message --- On Mar 22, 2020, at 9:49 AM, Michael Tuexen wrote: > I would support this. However, last time I tried this, I was not successful. > There were not very interested in defining a file format... They've done so in the past: https://tools.ietf.org/html/rfc1761 (and

Re: [tcpdump-workers] New RFCs for 1) pcap file format and 2) rpcapd protocol?

2020-03-21 Thread Guy Harris via tcpdump-workers
--- Begin Message --- On Mar 21, 2020, at 2:14 PM, Guy Harris via tcpdump-workers wrote: > The options I see are: 4) add a new team for rpcap, as it's a protocol rather than a file format, and thus only indirectly tied to pcap/pcapng, and putting the pcap format in the pcapng team beca

Re: [tcpdump-workers] New RFCs for 1) pcap file format and 2) rpcapd protocol?

2020-03-21 Thread Guy Harris via tcpdump-workers
--- Begin Message --- On Mar 21, 2020, at 2:31 PM, Mario Rugiero via tcpdump-workers wrote: > El sáb., 21 mar. 2020 18:15, Guy Harris via tcpdump-workers > escribió: > >> 1) has the slight disadvantage that the name for the team suggests it's >> for pcapng only; it a

  1   2   3   4   5   6   7   8   9   10   >