[tcpdump-workers] Re: Dropping support in tcpdump for older versions of libpcap?
--- Begin Message --- On 25/04/2024 12:25, Denis Ovsienko wrote: > On Fri, 19 Apr 2024 11:18:47 -0700 > Guy Harris wrote: > >> 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 software can copy something that works well in >>> tcpdump. It is not entirely obvious the LIBPCAP_HAVE_PCAP_ >>> macros would be worth the burden of maintenance, but the version >>> macros should be a straightforward improvement, something such as: >>> >>> #define PCAP_VERSION_MAJOR 1 >>> #define PCAP_VERSION_MINOR 11 >>> #define PCAP_VERSION_PATCHLEVEL 0 >>> #define PCAP_VERSION_AT_LEAST(a, b, c) ... >>> >>> (The GCC and Clang version checks in compiler-tests.h would be >>> examples of a good macro structure; Sun C, XL C and HP C version >>> checks look unwieldy and error-prone). >> >> Presumably meaning that we should export version information in the >> way GCC and Clang do, rather than in the ways that Sun/Oracle C, XL C >> and HP C do, the latter being why we have to go through all that >> extra pain (they provide a single #define with the version number >> components packed in it - or two different defines in different >> versions as XL C does - rather than separate #defines for major and >> minor versions, as GCC and Clang do). > > On a second thought, the best way to describe the desired result would > be that from the library users' point of view the version macros should > be easy to use correctly and difficult to use incorrectly. This would > justify some inconvenience in the library code, if necessary. > > An advantage of correctly sized BCD versions is that two packed integer > values compare in a straightforward way, so every end user does not > have to remember how to compare two version triplets correctly. A > disadvantage of BCD versions is the need to unpack them if one needs > individual components. > > Perhaps the best balance would be in defining the individual version > components as individual macros, and defining one-way "make this a BCD" > and "make the current libpcap version a BCD" macros. > > For example, instead of > > // require libpcap >= 1.10.2 > PCAP_VERSION_MAJOR > 1 || > (PCAP_VERSION_MAJOR == 1 && PCAP_VERSION_MINOR > 10) || > (PCAP_VERSION_MAJOR == 1 && PCAP_VERSION_MINOR == 10 && > PCAP_VERSION_PATCH >= 2) > > the users could use the following: > > // require libpcap >= 1.10.2 > PCAP_VERSION_BCD_CURRENT >= PCAP_VERSION_BCD(1, 10, 2) > > (where the exact number of bits allocated to each version component and > the definitions of PCAP_VERSION_BCD_CURRENT and PCAP_VERSION_BCD() are > an internal detail so long as the same values compare the same in > different versions of libpcap) > >>> There could be a run-time check as well: >>> >>> extern int pcap_version_at_least (unsigned char major, unsigned char >>> minor, unsigned char patchlevel); >> >> So how would that be used? >> >> If a program is dynamically linked with libpcap, and includes calls >> to routines that were added in libpcap 1.12 or later, if you try to >> run it with libpcap 1.11, the run-time linker will fail to load it, >> as some symbols requested by the executable won't be present in the >> library. The only OS on which this can be made to work is macOS, with >> its weak linking mechanism: > > [...] > >> But *all* of those require either run-time checks for a particular OS >> version in macOS, in cases where you're using the libpcap that comes >> with macOS, or require loading the library at run time, finding >> particular routines at run time, and checking at run time whether the >> routine was found. > > Thank you for the overview of weak linking means. I suppose it would be > best to keep out of this space to keep the task relatively manageable. > The only use case for the C function I currently see is the > command-line version tester. > >>> The latter could be available via a build helper binary, such as >>> (using the binary operators from test(1) and version-aware >>> comparison): >>> >>> pcap-version -ge 1 # same as 1 0 0 >>> pcap-version -ge 1 10 # same as 1 10 0 >>> pcap-version -ne 1 10 4 >>> pcap-version -eq 1 10 4 >>> pcap-version -ge 1 9 1 && pcap-version -le 1 9 3 >> >> So would this be used in a Makefile/configure >> script/CMakeFile.txt/etc. to check whether the libpcap on the system >> is sufficiently recent to include the routines your program needs, >> and fail if it isn't? > > Yes (as the tcpdump dependency would be). And not just the routines, > but their behaviour, as some software could require. > 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? >>> >>> Such use cases may exist, but I am not aware of any. >> >> So my inclination would be
[tcpdump-workers] Re: openwrt Conclusions from CVE-2024-3094 (libxz disaster)
--- Begin Message ---
On 01/04/2024 20:18, Guy Harris wrote:
> 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,tcpslice} version X.Y.Z, do
>
> git clone {repository}
>
> and then check out Git tag {libpcap,tcpdump,tcpslice}-X.Y.Z?
>
> If so, do we
>
> 1) require people to have autotools installed and run ./autogen.sh
>
> or
>
> 2) generate the configure scripts on some standard platform and check
> it in
>
> so that they have a configure script? Or is there some other way to arrange
> that people can get the configure scripts?
Even if we keep the tarball archive, we could have a host compromise (bad
autoconf, etc.) and if the "configure" script is generated on it, we risk to
open a door to an attack.
Thus, don't deliver "configure" in the tarball and ask to run "./autogen.sh"
with autotools installed.
--- End Message ---
___
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: openwrt Conclusions from CVE-2024-3094 (libxz disaster)
--- Begin Message ---
On 01/04/2024 20:18, Guy Harris wrote:
> 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,tcpslice} version X.Y.Z, do
>
> git clone {repository}
>
> and then check out Git tag {libpcap,tcpdump,tcpslice}-X.Y.Z?
>
> If so, do we
>
> 1) require people to have autotools installed and run ./autogen.sh
I vote for 1).
--- End Message ---
___
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
Re: [tcpdump-workers] [tcpdump] About HAVE_NO_PRINTF_Z
--- Begin Message --- On 12/01/2023 10:04, Denis Ovsienko wrote: > Do you think it would be > appropriate to use [again] %lu instead of %zu for size_t [...] on systems > that don't have %zu [...]? The problem is that the needed conversion specification is "%lu" on 64 bits system and "%u" on 32 bits system. --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] [tcpdump] About HAVE_NO_PRINTF_Z
--- Begin Message --- Hello, The commit fbd44158e0d5e6bb0c9b05671f702ebcf68cc56d was: --- Mend "make check" on Solaris 9 (Autoconf only). Sun C 5.9 does not support C99. GCC 4.6.4 recognizes -std=gnu99, but does not support the z length modifier in printf(3). In either case 18 tests fail in the following manner: < [...]: domain [length 0 < 12] (invalid) --- > [...]: domain [length 0 < zu] (invalid) Make these tests conditional and disable them when HAVE_NO_PRINTF_Z is defined. Modify the Autoconf leg of the build process to define the macro when printf() does not handle %zu as expected. The CMake leg looks broken on Solaris 9 with 2.8.9 now, so leave it be for now. --- I think that if a compiler builds a tcpdump that outputs "zu" when it must output "12", it's an error and this compiler must be tag "unsupported". Thus I propose to revert this commit and the cherry-picked one in 4.99 branch. (We have been requesting support from C99 since 2018.) -- Francois-Xavier --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Autoconf with Debian patches
--- Begin Message --- On 07/01/2023 20:13, Michael Richardson wrote: > > Francois-Xavier Le Bail via tcpdump-workers wrote: > > Or don't generate it and have the build process be: > > ./autogen.sh && ./configure && ... > > That just leads to non-deterministic builds for everyone :-( Could you explain why? My test with tcpslice on https://github.com/the-tcpdump-group/tcpslice/pull/16 gives "18 successful checks" on CI. (Some tests are with autoconf 2.69, some with 2.71) --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Autoconf with Debian patches
--- Begin Message --- On 06/01/2023 21:38, Francois-Xavier Le Bail 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 patches to >> Autoconf because traditionally the configure scripts were generated >> using non-Debian Autoconf. In practice this means that a regenerated >> revision of a configure script almost always requires "git add -p" >> instead of "git add". >> >> This has been discussed in some detail in [1], and my understanding is >> that making Debian Autoconf the new standard should make this problem >> smaller (it certainly would in my development environment). Would >> anybody like to make their point for or against such a switch in one of >> the next releases? >> >> 1: https://github.com/the-tcpdump-group/tcpslice/pull/12 > I agree to use Debian Autoconf 2.69. Or, perhaps better, remove the generated configure script from the repository. (See my previous message) --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Autoconf with Debian patches
--- Begin Message --- On 06/01/2023 23:49, Guy Harris via tcpdump-workers wrote: > An alternative would be *not* to keep the generated configure script in the > repository (that's what Wireshark ended up doing before it ceased to use > autoconf/automake), and generate it as part of the release-build process, > which we would do on a machine on which Debian autoconf was installed. Or don't generate it and have the build process be: ./autogen.sh && ./configure && ... > That requires that developers have autoconf installed if they're not going to > be using CMake, but there are already tools they need installed (a C > compiler, make, Flex, Bison/Berkeley YACC, ...) so I don't see that as a > problem. > > It also means that configure.ac and aclocal.m4 would have to work with > various sufficiently-recent versions of autoconf. FYI, test for tcpslice here: https://github.com/the-tcpdump-group/tcpslice/pull/16 Some warnings like The macro `XXX' is obsolete. (Some tests are with autoconf version 2.71) --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Autoconf with Debian patches
--- Begin Message --- On 04/01/2023 23:30, 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 patches to > Autoconf because traditionally the configure scripts were generated > using non-Debian Autoconf. In practice this means that a regenerated > revision of a configure script almost always requires "git add -p" > instead of "git add". > > This has been discussed in some detail in [1], and my understanding is > that making Debian Autoconf the new standard should make this problem > smaller (it certainly would in my development environment). Would > anybody like to make their point for or against such a switch in one of > the next releases? > > 1: https://github.com/the-tcpdump-group/tcpslice/pull/12 I agree to use Debian Autoconf 2.69. --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] About formalization of pcap expressions
--- Begin Message --- Hi, FYI, the author of the following document try a formalization of pcap expressions: https://www.seas.upenn.edu/~nsultana/files/pcap_semantics.pdf In this document, reference to a tool: https://gitlab.com/niksu/caper -- Francois-Xavier --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] [tcpdump] About struct in_addr / struct in6_addr
--- Begin Message --- On 17/07/2022 19:57, Guy Harris wrote: > 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' were replaced by 'nd_ipv6'. >> >> Remain: >> pflog.h:110:struct in_addr v4; >> pflog.h:111:struct in6_addr v6; >> >> Should they be replaced also? > > Yes. Dne in 71da7b139eb418ac91f1169c550e8a4dc970a692. OK, thank you. 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 --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] [tcpdump] About struct in_addr / struct in6_addr
--- Begin Message --- Hi, 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' were replaced by 'nd_ipv6'. Remain: pflog.h:110:struct in_addr v4; pflog.h:111:struct in6_addr v6; Should they be replaced also? -- Francois-Xavier --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] [tcpdump] New configure option for debugging
--- Begin Message --- > The usage is: > ./configure --enable-instrument-functions > > This should help some debugging processes. > > Enabling it generate instrumentation calls for entry and exit to functions. > Just after function entry and just before function exit, these profiling > functions are called and print the function names with indentation and call > level. > > To instrument a static function, remove temporarily the static specifier. The result output of the --enable-instrument-functions has been enhanced: It prints now, by default, also the static functions names. To configure the printing of only the global functions names, as before: $ make instrument_global To go back to print all the functions names: $ make instrument_all --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] [tcpdump] New configure option for debugging
--- Begin Message --- Hello, The usage is: ./configure --enable-instrument-functions This should help some debugging processes. Enabling it generate instrumentation calls for entry and exit to functions. Just after function entry and just before function exit, these profiling functions are called and print the function names with indentation and call level. To instrument a static function, remove temporarily the static specifier. -- Francois-Xavier --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] [libpcap] Keep Win32/Prj/* files ?
--- Begin Message --- On 07/12/2021 02:26, Denis Ovsienko via tcpdump-workers wrote: > On Mon, 6 Dec 2021 12:31:33 -0800 > Guy Harris wrote: > > [...] >> The CMake files are likely to be better maintained than the "use >> Visual Studio directly" files, as you don't need Visual Studio, and >> don't need to know how Visual Studio solution or project files work >> internal, in order to modify the CMake files. > The only way it makes sense to me is "these files can and should be > removed". OK, done. --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] [libpcap] Keep Win32/Prj/* files ?
--- Begin Message --- Hello, The information on building libpcap on Windows with Visual Studio is here: https://github.com/the-tcpdump-group/libpcap/blob/master/doc/README.Win32.md (The supported way to build libpcap (and tcpdump) on Windows is with CMake) Does anyone use these files? Win32/Prj/wpcap.sln Win32/Prj/wpcap.vcxproj Win32/Prj/wpcap.vcxproj.filters -- Francois-Xavier --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Saving packets with libpcap in PCAPNG format
--- Begin Message --- On 20/11/2021 20:55, Guy Harris wrote: > On Nov 20, 2021, at 11:41 AM, Francois-Xavier Le Bail via tcpdump-workers > wrote: > >> It's seems that Apple has changed their license to: "License: BSD." >> >> See: >> https://opensource.apple.com/source/libpcap/libpcap-98.40.1/libpcap/LICENSE.auto.html >> or >> https://opensource.apple.com/source/tcpdump/tcpdump-100.100.2/tcpdump/LICENSE.auto.html > > That's just the LICENSE file that comes with the libpcap release. > > However, the code to read pcapng files: > > > https://opensource.apple.com/source/libpcap/libpcap-98.40.1/libpcap/pcapng.c.auto.html > > is still licensed under the APSL: > > https://opensource.apple.com/apsl/ > > which contains the word "patent" in a number of locations, including: > > 12. Termination. > > 12.1Termination. This License and the rights granted hereunder > will terminate: > > (a) automatically without notice from Apple if You fail to comply > with any term(s) of this License and fail to cure such breach within 30 days > of becoming aware of such breach; > (b) immediately in the event of the circumstances described in > Section 13.5(b); or > (c) automatically without notice from Apple if You, at any time > during the term of this License, commence an action for patent infringement > against Apple; provided that Apple did not first commence an action for > patent infringement against You in that instance. Hello Guy, You are right, I miss that. Hello Rui Paulo, Could you ask to Apple management it they can change the license for libpcap (and tcpdump) to BSD, to help some work on pcapng support? Greetings --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Saving packets with libpcap in PCAPNG format
--- Begin Message --- On 06/12/2016 19:32, Guy Harris wrote: > On Dec 6, 2016, at 10:15 AM, Martin Dubuc wrote: > >> I am working on an application that requires to store packets in PCAPNG >> format. My understanding is that there isn't support for saving packets in >> PCAPNG format in the current code base. I have noticed that Apple has >> created an API in its custom version of libpcap (latest version can be >> viewed at https://opensource.apple.com/source/libpcap/libpcap-67/libpcap/ >> and is based on libpcap-1.7.4), and the extension seems to be open source. > > Open source *but* licensed under the Apple Public Source License Version 2.0: > > https://opensource.apple.com/apsl > > [...] > > I'm not sure whether the patent-related clauses - especially the > "Termination" clause - would cause any vendors or distributors who currently > include libpcap under its patent-clause-free BSD license not to want to > include it if it includes patent clauses of that sort. > >> Is there a plan to merge this to the libpcap at some point? Or is there >> plan to implement something else? > > My inclination was to implement *some* APIs for reading files (pcapng or > pcap, using the same API, so programs can transparently *read* either file > type), with the full capabilities of pcapng supported, and for writing pcapng > files, with a separate implementation. > > If we can get away with implementing Apple's API independently, under the > same BSD license as is used for the rest of libpcap, and that API can be used > to read either pcap or pcapng files, and it supports the full capabilities of > pcapng and allows support for future pcapng capabilities (as well as vendor > extensions), that would probably be the right choice; It's seems that Apple has changed their license to: "License: BSD." See: https://opensource.apple.com/source/libpcap/libpcap-98.40.1/libpcap/LICENSE.auto.html or https://opensource.apple.com/source/tcpdump/tcpdump-100.100.2/tcpdump/LICENSE.auto.html > otherwise, we'll implement a separate API, but try to do so in a way that > allows Apple to continue to provide their API. (They don't document the API > in any man page other than the pcapng man page in the source, so they might > consider it a private interface and be willing to use a different one, > especially if, as I expect we'll do, we provide a version of tcpdump that > supports the new API if available. --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] [www.tcpdump.org] favicon
--- Begin Message --- Hello, To keep coherent the visual identity of the project, I propose the attached favicon for the web site. -- Francois-Xavier--- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] [tcpdump] Finding inconsistent outputs of tcpdump with different compilers
--- Begin Message --- Hello, As a follow-up to https://github.com/the-tcpdump-group/tcpdump/issues/919, here is a way to help finding eventual inconsistent outputs. 1) Get libpcap and tcpdump from the-tcpdump-group:master branches in the same directory. git clone https://github.com/the-tcpdump-group/libpcap.git git clone https://github.com/the-tcpdump-group/tcpdump.git 2) Build libpcap (./configure && make -s clean all). 3) Build tcpdump with clang (CC=clang ./configure && make -s clean all). Rename tcpdump to tcpdump_clang. 4) Build tcpdump with gcc (CC=gcc ./configure && make -s clean all). Rename tcpdump to tcpdump_gcc. 5) Run the following script on all the pcap(ng) files you have access. (Update PCAP_DIRS...) 6) Report any output giving the OS, clang and gcc versions. Notes: a) The script may need some update (TMPDIR for some systems). b) It also could be updated to use compilers different from clang/gcc... #!/bin/bash PCAP_DIRS='dir1 dir2 ...' TMPDIR=/dev/shm/diff_2_compilers_$$ mkdir -p $TMPDIR TCPDUMP_1=tcpdump_clang TCPDUMP_2=tcpdump_gcc while read -r p; do rm -f $TMPDIR/* file -b "$p" | grep capture >/dev/null || continue ./$TCPDUMP_1 -#Hen -r "$p" >$TMPDIR/out1 2>$TMPDIR/err1 ./$TCPDUMP_2 -#Hen -r "$p" >$TMPDIR/out2 2>$TMPDIR/err2 cmp $TMPDIR/out1 $TMPDIR/out2 >/dev/null [ $? = 1 ] && echo "$p" && diff $TMPDIR/out1 $TMPDIR/out2 && echo sed -i "s/$TCPDUMP_1/$TCPDUMP_2/" $TMPDIR/err1 cmp $TMPDIR/err1 $TMPDIR/err2 >/dev/null [ $? = 1 ] && echo "$p" && diff $TMPDIR/err1 $TMPDIR/err2 && echo done < <(find $PCAP_DIRS -type f -not -path '*/\.git/*' -not -path '*/\.svn/*'|sort) Greetings, -- Francois-Xavier --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Stick with Travis for continuous integration, or switch?
--- Begin Message --- On 03/02/2021 17:50, Francois-Xavier Le Bail via tcpdump-workers wrote: > These scripts can be used locally for build tests, used on other CI and > easily be updated to run new tests (32 bits builds, sanitizers, coverage, > etc). > > Next step is doing similar setup for tcpdump... Done with commit 973e9c1c9c12bdab5e038c364e62bd099d3645ec. Some updates after. --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Stick with Travis for continuous integration, or switch?
--- Begin Message --- On 01/02/2021 18:08, Denis Ovsienko via tcpdump-workers wrote: > On Mon, 18 Jan 2021 22:29:21 -0800 > Guy Harris via tcpdump-workers > wrote: > >> I guess we meet those requirements, although I'm not too keen on >> having to keep going hat-in-hand to them every time we run out of >> credits; hopefully, we can just get a renewable amount. > I had requested a renewable OSS allowance on 29 January, got the > template response and confirmed the details. Let's see where it goes. > The account is at 3790/1 credits as of today, in other words, three > more builds of libpcap or at most one tcpdump build, if/when the latter > migrates. To save CI runtime, I have committed a063c2d21417345ee583551ef2c07a0be6b32696 for libpcap. This will currently run only five builders (amd64, arm64, ppc64le, s390x and osx) and do the matrix processing with scripts. We can build with ~ half the time (Total time ~26 mins). These scripts can be used locally for build tests, used on other CI and easily be updated to run new tests (32 bits builds, sanitizers, coverage, etc). Next step is doing similar setup for tcpdump... --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] libpcap detection and linking in tcpdump
--- Begin Message --- On 07/01/2021 18:35, Bill Fenner via tcpdump-workers wrote: > These jobs are still failing, but now for a different reason. The build > succeeds, but the tests fail - the tests that require the new libpcap. > However, if you augment TESTrun to print the version, it says > 1.11.0-PRE-GIT but the tests that need the new libpcap still fail. My hypothesis is that, with the cmake build, for some reason, tcpdump linked to the 1.11.0-PRE-GIT local library was built with include files for the system libpcap not the local libpcap ones, thus DLT_DSA_TAG_BRCM and some other macros (which exist only in the new libpcap) are undefined (hence the UNSUPPORTED outputs). '-I' configuration problem? (The autoconf build add in the Makefile: INCLS = -I. -I../libpcap) -- Francois-Xavier --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] [tcpdump] After setjmp/longjmp update
--- Begin Message --- On 18/12/2020 21:36, Francois-Xavier Le Bail via tcpdump-workers wrote: > The post setjmp/longjmp updates take more time than expected. About 30% of > the work is done. > To avoid keeping too long the other updates in the master branch, we plan to > release soon a 4.99.0 > version. 5.0.0 will be the released later when all the "pre-longjmp" logic > will be removed. > In this transitional step the only visible effect should be that the -x/-X > options will not always > show the link-layer header in truncation cases. Hello, Releases done: libpcap version 1.10.0 tcpdump version 4.99.0 https://www.tcpdump.org/index.html#latest-releases --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] [tcpdump] After setjmp/longjmp update
--- Begin Message --- On 05/09/2020 18:20, Francois-Xavier Le Bail via tcpdump-workers wrote: > Hello, > > Some people ask for a new version of tcpdump. > > To understand why we cannot release now, here is some information: > > We are in the process to harden the tcpdump code with use of new (GET_) > macros (with setjmp/longjmp > logic) to fetch the packet data without have to do ND_TCHECK_/ND_TTEST_ macro > calls before EXTRACT_ > macros calls. > > [...] Hello, The post setjmp/longjmp updates take more time than expected. About 30% of the work is done. To avoid keeping too long the other updates in the master branch, we plan to release soon a 4.99.0 version. 5.0.0 will be the released later when all the "pre-longjmp" logic will be removed. In this transitional step the only visible effect should be that the -x/-X options will not always show the link-layer header in truncation cases. -- Francois-Xavier --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] [tcpdump] After setjmp/longjmp update
--- Begin Message --- On 24/09/2020 21:51, Denis Ovsienko via tcpdump-workers wrote: > On Sat, 5 Sep 2020 18:20:42 +0200 > Francois-Xavier Le Bail via tcpdump-workers > wrote: > > [...] >> 2) Process all the truncated cases with: >> ndo->ndo_ll_hdr_len = 0; >> longjmp(ndo->ndo_truncated, 1); >> (With a new macro, like 'ND_TRUNCATED' or 'ND_IS_TRUNCATED') > [...] > > It could be simpler and more reliable to reset or to ignore > ndo->ndo_ll_hdr_len in pretty_print_packet() after "returning" from > setjmp for the second time (longjmp() can happen in many different > places, but there is only one setjmp()). Agreed. Done with commit 387c58edb5f053eb719d8e9cdf05d626d367bddd. --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] [tcpdump] After setjmp/longjmp update
--- Begin Message ---
On 20/09/2020 18:28, Michael Richardson wrote:
>
> Given:
>
> case CTRL_BA:
> (*) ND_TCHECK_LEN(p, CTRL_BA_HDRLEN);
> if (!ndo->ndo_eflag)
> ND_PRINT(" RA:%s ",
> GET_ETHERADDR_STRING(((const struct ctrl_ba_hdr_t
> *)p)->ra));
> break;
>
> If we remove (*), if the eflag is not set, then the GET_ETHERADDR_STRING()
> won't be called, and there will be no truncated warning at this point.
> Is that the right thing?
Answer here:
https://github.com/the-tcpdump-group/tcpdump/pull/875#pullrequestreview-493054552
(point 3)
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] [tcpdump] After setjmp/longjmp update
--- Begin Message --- On 20/09/2020 18:25, Michael Richardson wrote: > > Also, please confirm for me that these lines like this are redundant: > > ND_TCHECK_LEN(p, IEEE802_11_REASON_LEN); > if (length < IEEE802_11_REASON_LEN) > goto trunc; > > In fact, we don't need/want either of them anymore, because the GET_* will > handle the range check. Answer here: https://github.com/the-tcpdump-group/tcpdump/pull/875#pullrequestreview-493054552 (point 4) --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] [tcpdump] After setjmp/longjmp update
--- Begin Message ---
On 17/09/2020 22:05, Francois-Xavier Le Bail via tcpdump-workers wrote:
> On 17/09/2020 16:15, Denis Ovsienko via tcpdump-workers wrote:
>> On Sat, 5 Sep 2020 18:20:42 +0200
>> Francois-Xavier Le Bail via tcpdump-workers
>> wrote:
>>
>>> 2) Process all the truncated cases with:
>>> ndo->ndo_ll_hdr_len = 0;
>>> longjmp(ndo->ndo_truncated, 1);
>>> (With a new macro, like 'ND_TRUNCATED' or 'ND_IS_TRUNCATED')
>> The master branch now has a change along these lines. Whilst preparing
>> changes to a couple decoders based on that (still work in progress), I
>> managed to make some observations, will post as soon as it all looks
>> good and makes sense.
> Should we have something like:
>
> if (setjmp(ndo->early_end) == 0) {
> /* Print the packet. */
> (ndo->ndo_if_printer)(ndo, h, sp);
> } else {
> switch (ndo->early_end_reason) {
> case TRUNCATED:
> /* A printer quit because the packet was truncated;
> report it */
> nd_print_trunc(ndo);
> break;
> case INVALID:
> ...
> }
> }
>
> (ndo->ndo_truncated -> ndo->early_end and ndo->early_end_reason =
> TRUNCATED/INVALID/other?
Or perhaps better (no need for a 'early_end_reason' field):
switch (setjmp(ndo->early_end)) {
case 0:
/* Print the packet. */
(ndo->ndo_if_printer)(ndo, h, sp);
break;
case ND_TRUNCATED:
/* A printer quit because the packet was truncated; report it */
nd_print_trunc(ndo);
break;
case ND_INVALID:
ND_PRINT(" (invalid)"); /* or calling a function that do the
print */
}
With:
#define ND_TRUNCATED 1
#define ND_INVALID 2
and use
longjmp(ndo->early_end, ND_TRUNCATED); /* for packet truncated cases */
longjmp(ndo->early_end, ND_INVALID); /* for invalid cases (bad length, etc.)
*/
--
Francois-Xavier
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] [tcpdump] After setjmp/longjmp update
--- Begin Message ---
On 17/09/2020 16:15, Denis Ovsienko via tcpdump-workers wrote:
> On Sat, 5 Sep 2020 18:20:42 +0200
> Francois-Xavier Le Bail via tcpdump-workers
> wrote:
>
>> 2) Process all the truncated cases with:
>> ndo->ndo_ll_hdr_len = 0;
>> longjmp(ndo->ndo_truncated, 1);
>> (With a new macro, like 'ND_TRUNCATED' or 'ND_IS_TRUNCATED')
> The master branch now has a change along these lines. Whilst preparing
> changes to a couple decoders based on that (still work in progress), I
> managed to make some observations, will post as soon as it all looks
> good and makes sense.
Should we have something like:
if (setjmp(ndo->early_end) == 0) {
/* Print the packet. */
(ndo->ndo_if_printer)(ndo, h, sp);
} else {
switch (ndo->early_end_reason) {
case TRUNCATED:
/* A printer quit because the packet was truncated;
report it */
nd_print_trunc(ndo);
break;
case INVALID:
...
}
}
(ndo->ndo_truncated -> ndo->early_end and ndo->early_end_reason =
TRUNCATED/INVALID/other?
--
Francois-Xavier
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] [tcpdump] After setjmp/longjmp update
--- Begin Message ---
On 07/09/2020 16:43, Denis Ovsienko via tcpdump-workers wrote:
> On Sat, 5 Sep 2020 18:20:42 +0200
> Thank you for posting a detailed explanation and making the first round
> of changes. I am looking into the logic of this work. As soon as it
> feels I can tell the right instances of ND_TCHECK() to remove from the
> wrong ones, I am going to convert some more code manually if that's OK.
That's OK, just try to avoid those like:
ND_TCHECK_LEN(e, sizeof(nd_ipv4)) calls followed by a GET_IPADDR_STRING(e)
call, same e.
ND_TCHECK_4(e) calls followed by a GET_IPADDR_STRING(e) call, same e.
ND_TCHECK_LEN(e, sizeof(nd_ipv6)) calls followed by a GET_IP6ADDR_STRING(e)
call, same e.
ND_TCHECK_16(e) calls followed by a GET_IP6ADDR_STRING(e) call, same e.
(I am working to remove them)
> [...]
>
>> C) The -x printing begins now by:
>>
>> 028e: Begin of destination MAC address, IPv4 is 14 octets after.
>>
>> ./tcpdump -#envx -r krb-truncated.pcap
> The .pcap file in your examples is not in the repository, but I could
> reconstruct it to get the same output as yours. For convenience here is
> a hex dump of my .pcap file ("xxd -r -p" to restore):
>
> d4c3b2a10200040045000100
> 45000400028e00506ae10101fc83080045088034d940
> 400040116a700a0100ea9ad600585e0a028000b104020f0f0f0f0f15
> 0f040f0f0f0f0f0f0f0f0f0f0f0f001688
Yes, it's pkt#15 from tests/babel_update_oobr.pcap.
(extracted with editcap from Wireshark)
>> reading from file krb-truncated.pcap, link-type EN10MB (Ethernet),
>> snapshot length 69 1 01:00:00.00 01:01:fc:83:00:00 >
>> 02:8e:00:50:6a:e1, ethertype IPv4 (0x0800), length 262144: (tos 0x8,
>> ttl 64, id 55616, offset 0, flags [DF], proto UDP (17), length 32820,
>> bad cksum 6a70 (->3baf)!) 10.0.0.1.88 > 0.234.154.214.24074: v4 be
>> KDC_REQUEST: ^O^O^O^O^O^U.@^O^D^O^O^O^O^O^O^O^O^O^O^O^O [|krb]
>> 0x: 028e 0050 6ae1 0101 fc83 0now 000 0800 4508
> Just to confirm, "now" in the line above is not a part of the output,
> right?
Yes!
>> 0x0010: 8034 d940 4000 4011 6a70 0a00 0001 00ea
>> 0x0020: 9ad6 0058 5e0a 0280 00b1 0402 0f0f 0f0f
>> 0x0030: 0f15 0f04 0f0f 0f0f 0f0f 0f0f 0f0f
>> 0x0040: 0f0f 0016 88
> I confirm the patch changes the hex output exactly as described.
--
Francois-Xavier
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] [tcpdump] After setjmp/longjmp update
--- Begin Message ---
Hello,
Some people ask for a new version of tcpdump.
To understand why we cannot release now, here is some information:
We are in the process to harden the tcpdump code with use of new (GET_) macros
(with setjmp/longjmp
logic) to fetch the packet data without have to do ND_TCHECK_/ND_TTEST_ macro
calls before EXTRACT_
macros calls.
They were some preliminary stages (for example: add and use nd_ types, more
EXTRACT_XXX() calls,
rename EXTRACT_XXX(), ND_TTEST_XXX() and ND_TCHECK_XXX macros, use
EXTRACT_[SU]_1() to replace
direct dereferences, etc.).
The first step was to replace almost all the EXTRACT_ calls by GET_ calls.
See:
-176e182416d822df0f9d4695410479e8b17a07b3 (Apply the first step of the new way
to fetch data with
bounds checking)
-ee68aa36460d7efeca48747f33b7f2adc0900bfb (Use the new GET_ macros instead of
the EXTRACT_ ones)
After we had to manage this warning:
After we have had this warning:
./print.c: In function 'pretty_print_packet':
./print.c:342:8: warning: variable 'hdrlen' might be clobbered by 'longjmp' or
'vfork' [-Wclobbered]
342 | u_int hdrlen = 0;
|^~
therefore, the second step was:
-757e793ca521cbfdc4a6104c9a2a920f5538d195 (Apply the first step of the new way
to update the
link-layer header length)
- ~30 commits
-b30f3843b93c11e897e6da91abf709a716ae (Apply the last step of the new way
to update the
link-layer header length)
There are now redundant bounds checks because most of the GET_.*_n(e) macros
are preceded by a
ND_TCHECK_n(e) call (same n, same e). There are also two ways to process the
truncated cases:
GET_ only (via longjmp) or ND_TCHECK_/ND_TTEST_ before GET_ going back all the
functions called.
As a consequence of these two ways to process the truncated cases, the -x/-X
output may be not the same.
Example of a Kerberos truncated packet:
A) Currently we have:
./tcpdump -#envx -r krb-truncated.pcap
reading from file krb-truncated.pcap, link-type EN10MB (Ethernet), snapshot
length 69
1 01:00:00.00 01:01:fc:83:00:00 > 02:8e:00:50:6a:e1, ethertype IPv4
(0x0800), length
262144: (tos 0x8, ttl 64, id 55616, offset 0, flags [DF], proto UDP (17),
length 32820, bad cksum
6a70 (->3baf)!)
10.0.0.1.88 > 0.234.154.214.24074: v4 be KDC_REQUEST:
^O^O^O^O^O^U.@^O^D^O^O^O^O^O^O^O^O^O^O^O^O [|krb]
0x: 4508 8034 d940 4000 4011 6a70 0a00 0001
0x0010: 00ea 9ad6 0058 5e0a 0280 00b1 0402 0f0f
0x0020: 0f0f 0f15 0f04 0f0f 0f0f 0f0f 0f0f
0x0030: 0f0f 0f0f 0016 88
The -x printing begins by:
4508: IPv4 with tos 0x08: OK
B) Testing a patch to remove now useless ND_TCHECK_1() checks (because of
GET_[SU]_1() uses)
$ git diff
-
diff --git a/print-krb.c b/print-krb.c
index 41a6126a..c6c2fe7d 100644
--- a/print-krb.c
+++ b/print-krb.c
@@ -168,8 +168,6 @@ krb4_print(netdissect_options *ndo,
kp = (const struct krb *)cp;
- ND_TCHECK_1(kp->type);
-
type = GET_U_1(kp->type) & (0xFF << 1);
ND_PRINT(" %s %s: ",
@@ -181,7 +179,6 @@ krb4_print(netdissect_options *ndo,
if ((cp = krb4_print_hdr(ndo, cp)) == NULL)
return;
cp += 4;/* ctime */
- ND_TCHECK_1(cp);
ND_PRINT(" %umin ", GET_U_1(cp) * 5);
cp++;
PRINT;
@@ -191,14 +188,11 @@ krb4_print(netdissect_options *ndo,
case AUTH_MSG_APPL_REQUEST:
cp += 2;
- ND_TCHECK_1(cp);
ND_PRINT("v%u ", GET_U_1(cp));
cp++;
PRINT;
- ND_TCHECK_1(cp);
ND_PRINT(" (%u)", GET_U_1(cp));
cp++;
- ND_TCHECK_1(cp);
ND_PRINT(" (%u)", GET_U_1(cp));
break;
-
C) The -x printing begins now by:
028e: Begin of destination MAC address, IPv4 is 14 octets after.
./tcpdump -#envx -r krb-truncated.pcap
reading from file krb-truncated.pcap, link-type EN10MB (Ethernet), snapshot
length 69
1 01:00:00.00 01:01:fc:83:00:00 > 02:8e:00:50:6a:e1, ethertype IPv4
(0x0800), length
262144: (tos 0x8, ttl 64, id 55616, offset 0, flags [DF], proto UDP (17),
length 32820, bad cksum
6a70 (->3baf)!)
10.0.0.1.88 > 0.234.154.214.24074: v4 be KDC_REQUEST:
^O^O^O^O^O^U.@^O^D^O^O^O^O^O^O^O^O^O^O^O^O [|krb]
0x: 028e 0050 6ae1 0101 fc83 0now 000 0800 4508
0x0010: 8034 d940 4000 4011 6a70 0a00 0001 00ea
0x0020: 9ad6 0058 5e0a 0280 00b1 0402 0f0f 0f0f
0x0030: 0f15 0f04 0f0f 0f0f 0f0f 0f0f 0f0f
0x0040: 0f0f 0016 88
We have:
1) The "old" way, before the patch, returning from all functions and at the end
returning the header
length to the link-layer dissector (xxx_if_print), updating the
'ndo->ndo_ll_hdr_len' field (output A).
b) The "longjmp" way with
Re: [tcpdump-workers] strlcpy() in tcpslice
--- Begin Message --- On 25/08/2020 19:44, Denis Ovsienko via tcpdump-workers wrote: > +[missing/strlcpy.c:46]: (style) The function 'strlcpy' is never used. > > (Which is true, but neither GCC nor Clang complain about that.) > > LBL code never used strlcpy(), it appeared in TTG code in 2001 via > commit fc7de60. Considering long-term maintenance, would it be better > to lose the unused missing/strlcpy.c now, or to wait a bit, or to keep > it around for as long as it compiles? Hello Denis, strlcpy is used here: tcpslice.c:999: strlcpy(buf, asctime(t), 128); With my build: gcc [...] -g -O2 -o strlcpy.o -c ./missing/strlcpy.c -- Francois-Xavier --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] [tcpdump] Keep win32/prj/WinDump.dsp ?
--- Begin Message --- On 08/06/2020 21:50, Guy Harris wrote: > 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 versions of Visual Studio has CMake as an > installable component. > > If nobody else has said "no, I need them!" - and volunteered to take > responsibility for maintaining them! - I'd say we should get rid of them, as > we're not maintaining them. (CMake files 1) can handle multiple versions of > Visual Studio and 2) are intended to be maintainable by people using a text > editor rather than generated by a big IDE that runs primarily, if not > exclusively, on Windows.) Nobody has said 'we need to keep them', removed. --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Reading capture files with an unknown link-layer header type
--- Begin Message --- On 12/06/2020 07:31, Guy Harris via tcpdump-workers wrote: > 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, pcap_compile(), in *libpcap*, will fail with an unknown header type > - and tcpdump always hands a filter to pcap_compile(), even if it's a null > string (which means "accept every packet"). > > It doesn't fail with *known* filter types for which most filters are > unsupported, it just rejects most of them (other than "link[M:N]"). > > Is there any reason *not* handle link-layer types unknown to libpcap in > pcap_compile()? No reason. We should decode them in hex/ASCII like with the previous change with perhaps a warning like: "Warning: link-type 290 is not in libpcap range" --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] [tcpdump] Keep win32/prj/WinDump.dsp ?
--- Begin Message --- On 25/05/2020 00:22, Guy Harris wrote: > 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 can more easily be kept up-to-date by UN*X users adding a > new dissector than can Windows project files, and which are tested by the > Travis/AppVeyor CI builds). CMake can generate project files for several > versions of Visual Studio, as well as build files for various other build > systems. > > See > > > https://github.com/the-tcpdump-group/tcpdump/blob/master/doc/README.Win32.md > > for information on building tcpdump on Windows with Visual Studio (and > > > https://github.com/the-tcpdump-group/libpcap/blob/master/doc/README.Win32.md > > for information on building libpcap on Windows with Visual Studio). OK. Thus all the files in win32/prj/ could be removed? (WinDump.dsp WinDump.dsw WinDump.sln WinDump.vcproj) --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] [tcpdump] Keep win32/prj/WinDump.dsp ?
--- Begin Message --- Hello, 15 printers are missing in win32/prj/WinDump.dsp. Does anyone use it? Any reason to keep it ? Greetings, -- Francois-Xavier --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Compile libpcap with DLT_LINUX_SLL2
--- Begin Message --- On 10/05/2020 10:04, Francois-Xavier Le Bail via tcpdump-workers wrote: > On 10/05/2020 00:37, Guy Harris via tcpdump-workers wrote: >> Is SLL2 sufficiently established that we'd have to introduce an SLL3 type, >> or can we just change SLL2 at this point? > Just on the SLL2/SLL3 point: > > libpcap-1.9.1 is the first libpcap release to support SLL2, but > -No tcpdump currently release version supports SLL2. > -No Wireshark currently release version supports SLL2. > -As said in a previous message Snort, Scapy, Zeek don't support it. > > Therefore SLL2 use does not seem "sufficiently established" and we can just > change it. Not sure now ... We have to make tcpdump work with the already released libpcap 1.9.1 and current SLL2. If we update SLL2 and therefore tcpdump, can we make tcpdump works when linked to 1.9.1? -- Francois-Xavier --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Compile libpcap with DLT_LINUX_SLL2
--- Begin Message --- On 10/05/2020 00:37, Guy Harris via tcpdump-workers wrote: > Is SLL2 sufficiently established that we'd have to introduce an SLL3 type, or > can we just change SLL2 at this point? Just on the SLL2/SLL3 point: libpcap-1.9.1 is the first libpcap release to support SLL2, but -No tcpdump currently release version supports SLL2. -No Wireshark currently release version supports SLL2. -As said in a previous message Snort, Scapy, Zeek don't support it. Therefore SLL2 use does not seem "sufficiently established" and we can just change it. -- Francois-Xavier --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] LINUX_SLL2 printing update
--- Begin Message --- On 09/05/2020 07:17, Guy Harris wrote: > 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 Done with 2b5ab9ae73292ee9e0cc01b86e127d9079a78fb2. --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] LINUX_SLL2 printing update
--- Begin Message --- Hello, As a user, I think the current print with LINUX_SLL2 on the "any" interface is not optimal. tcpdump -nt: ifindex 2 (eth0) IP 192.168.1.1 > 9.9.9.9: ICMP echo request, id 1098, seq 1, length 64 ifindex 2 (eth0) IP 9.9.9.9 > 192.168.1.1: ICMP echo reply, id 1098, seq 1, length 64 tcpdump -nte: ifindex 2 (eth0) Out 00:50:79:ab:cd:ef ethertype IPv4 (0x0800), length 104: 192.168.1.1 > 9.9.9.9: ICMP echo request, id 1109, seq 1, length 64 ifindex 2 (eth0) In 00:50:79:12:34:56 ethertype IPv4 (0x0800), length 104: 9.9.9.9 > 192.168.1.1: ICMP echo reply, id 1109, seq 1, length 64 For a quick look, I don't need 'ifindex N', but I need 'In/Out,...' Thus I propose to print: tcpdump -nt: eth0 Out 192.168.1.1 > 9.9.9.9: ICMP echo request, id 1109, seq 1, length 64 eth0 In 9.9.9.9 > 192.168.1.1: ICMP echo reply, id 1109, seq 1, length 64 tcpdump -nte: eth0 Out ifindex 2 00:50:79:ab:cd:ef ethertype IPv4 (0x0800), length 104: 192.168.1.1 > 9.9.9.9: ICMP echo request, id 1109, seq 1, length 64 eth0 In ifindex 2 00:50:79:12:34:56 ethertype IPv4 (0x0800), length 104: 9.9.9.9 > 192.168.1.1: ICMP echo reply, id 1109, seq 1, length 64 We can change because the printing is currently not supported in any release version, thus no usage/habit/greping really defined. -- Francois-Xavier --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Compile libpcap with DLT_LINUX_SLL2
--- Begin Message --- On 08/05/2020 22:59, Francois-Xavier Le Bail via tcpdump-workers wrote: >> > In fact, no need to change libpcap. Can be do in tcpdump code. >> >> > See: https://github.com/the-tcpdump-group/tcpdump/pull/850 >> >> definitely do this in tcpdump. > Done. So for tcpdump in current master, DLT_LINUX_SLL2 is the new default for the "any" interface with libpcap >= 1.9.1 (version 1.9.1 and libpcap in current master). -- Francois-Xavier --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Compile libpcap with DLT_LINUX_SLL2
--- Begin Message --- On 08/05/2020 19:59, Michael Richardson wrote: > > Francois-Xavier Le Bail via tcpdump-workers wrote: > >>> BTW how about DLT_LINUX_SLL2 as the default? What does it block? > > >> To avoid breaking program that cannot use SLL2, could we have an API > >> like pcap_set_cooked_default_ssl2() or pcap_set_default_ssl2_on_any() > >> and use it in tcpdump? > > > In fact, no need to change libpcap. Can be do in tcpdump code. > > > See: https://github.com/the-tcpdump-group/tcpdump/pull/850 > > definitely do this in tcpdump. Done. -- Francois-Xavier --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] decode MPLS-contained packets?
--- Begin Message --- On 07/05/2020 15:39, Francois-Xavier Le Bail wrote: > On 07/05/2020 09:39, Francois-Xavier Le Bail via tcpdump-workers wrote: >>> In this *particular* case, that test is done only if the uppermost nibble >>> of the uppermost octet is 0, so that would only be the case for the source >>> address, which is less likely to be a group address than the destination >>> address. There may be other places where that heuristic dissector is used, >>> however. >> Ok. >> What if the first nibble is <> de 4, 6, 1, 0, e.g. 'f' like the first f of >> ff:ff:ff:ff:ff:ff ? > > Currently tshark don't decode if first nibble is <> de 4, 6, 1, 0: > (ARP request not seen, just "Data") > --- > MultiProtocol Label Switching Header, Label: 262145, Exp: 0, S: 1, TTL: 253 > 0100 0001 = MPLS Label: 262145 > 000. = MPLS Experimental Bits: 0 > ...1 = MPLS Bottom Of Label Stack: 1 > 1101 = MPLS TTL: 253 > Data (64 bytes) > > ff ff ff ff ff ff 00 50 79 66 68 01 08 06 00 01 ...Pyfh. > 0010 08 00 06 04 00 01 00 50 79 66 68 01 0a 48 01 42 ...Pyfh..H.B > 0020 ff ff ff ff ff ff 0a 48 01 43 00 00 00 00 00 00 ...H.C.. > 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > Data: > 005079666801080600010800060400010050796668010a480142 > <80> > [Length: 64] > --- > 1 16:26:10.061638 ca:04:2c:7e:00:08 > 00:b5:df:d1:63:02, ethertype MPLS > unicast (0x8847), > length 82: MPLS (label 262145, exp 0, [S], ttl 253) > 00:50:79:66:68:01 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length > 64: Ethernet (len 6), > IPv4 (len 4), Request who-has 10.72.1.67 (ff:ff:ff:ff:ff:ff) tell 10.72.1.66, > length 50 > --- Already reported issue. Currently no fix. (https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13306) -- Francois-Xavier --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Compile libpcap with DLT_LINUX_SLL2
--- Begin Message --- On 31/03/2020 11:09, Francois-Xavier Le Bail via tcpdump-workers wrote: >> BTW how about DLT_LINUX_SLL2 as the default? What does it block? > To avoid breaking program that cannot use SLL2, could we have an API like > pcap_set_cooked_default_ssl2() or pcap_set_default_ssl2_on_any() and use it > in tcpdump? In fact, no need to change libpcap. Can be do in tcpdump code. See: https://github.com/the-tcpdump-group/tcpdump/pull/850 -- Francois-Xavier --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] decode MPLS-contained packets?
--- Begin Message ---
On 07/05/2020 09:39, Francois-Xavier Le Bail via tcpdump-workers wrote:
>> In this *particular* case, that test is done only if the uppermost nibble of
>> the uppermost octet is 0, so that would only be the case for the source
>> address, which is less likely to be a group address than the destination
>> address. There may be other places where that heuristic dissector is used,
>> however.
> Ok.
> What if the first nibble is <> de 4, 6, 1, 0, e.g. 'f' like the first f of
> ff:ff:ff:ff:ff:ff ?
Currently tshark don't decode if first nibble is <> de 4, 6, 1, 0:
(ARP request not seen, just "Data")
---
MultiProtocol Label Switching Header, Label: 262145, Exp: 0, S: 1, TTL: 253
0100 0001 = MPLS Label: 262145
000. = MPLS Experimental Bits: 0
...1 = MPLS Bottom Of Label Stack: 1
1101 = MPLS TTL: 253
Data (64 bytes)
ff ff ff ff ff ff 00 50 79 66 68 01 08 06 00 01 ...Pyfh.
0010 08 00 06 04 00 01 00 50 79 66 68 01 0a 48 01 42 ...Pyfh..H.B
0020 ff ff ff ff ff ff 0a 48 01 43 00 00 00 00 00 00 ...H.C..
0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Data:
005079666801080600010800060400010050796668010a480142
<80>
[Length: 64]
---
1 16:26:10.061638 ca:04:2c:7e:00:08 > 00:b5:df:d1:63:02, ethertype MPLS
unicast (0x8847),
length 82: MPLS (label 262145, exp 0, [S], ttl 253)
00:50:79:66:68:01 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length
64: Ethernet (len 6),
IPv4 (len 4), Request who-has 10.72.1.67 (ff:ff:ff:ff:ff:ff) tell 10.72.1.66,
length 50
---
--
Francois-Xavier
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] decode MPLS-contained packets?
--- Begin Message --- On 07/05/2020 09:17, Guy Harris 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 Wireshark's file giving manufacturer names for OUIs". >> What if the destination address is ff:ff:ff:ff:ff:ff (broadcast) for e.g. >> ARP request ? >> Or some multicast address ? > In this *particular* case, that test is done only if the uppermost nibble of > the uppermost octet is 0, so that would only be the case for the source > address, which is less likely to be a group address than the destination > address. There may be other places where that heuristic dissector is used, > however. Ok. What if the first nibble is <> de 4, 6, 1, 0, e.g. 'f' like the first f of ff:ff:ff:ff:ff:ff ? -- Francois-Xavier --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] decode MPLS-contained packets?
--- Begin Message ---
On 07/05/2020 09:13, Gert Doering wrote:
> Due to missing {}, the "p += 4" will always be executed, skipping the
> control word twice if "-v" is set.
Yes, already corrected, not the good patch ...
--
Francois-Xavier
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] decode MPLS-contained packets?
--- Begin Message --- 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 Wireshark's file giving manufacturer names for OUIs". What if the destination address is ff:ff:ff:ff:ff:ff (broadcast) for e.g. ARP request ? Or some multicast address ? -- Francois-Xavier --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] decode MPLS-contained packets?
--- Begin Message ---
On 05/05/2020 21:44, Gert Doering wrote:
> Hi,
>
> On Tue, May 05, 2020 at 08:47:04PM +0200, Francois-Xavier Le Bail 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 skip 4 bytes
>>> and the rest is a regular Ethernet packet" should work.
>>
>> We should print "PW Ethernet Control Word" and the "Sequence Number", 2 last
>> 2 octets of the 4.
>> Like:
>> PW Ethernet Control Word, Sequence Number xxx
>
> I think we should only print this if "-v" is given. Most of the time,
> both control word and sequence number are of little interest.
>
> I really like tcpdump's very compact "only the most relevant info" output
> format (by default).
Proposed patch attached.
With new '-T mplsethnocw' option to force 'Ethernet without Control Word'
decode.
(from Francesco Fondelli comment)
--
Francois-Xavier
diff --git a/netdissect.h b/netdissect.h
index 65a0d987..cd76d654 100644
--- a/netdissect.h
+++ b/netdissect.h
@@ -294,6 +294,7 @@ extern void nd_pop_all_packet_info(netdissect_options *);
#define PT_PTP 18 /* PTP */
#define PT_SOMEIP 19 /* Autosar SOME/IP Protocol */
#define PT_DOMAIN 20 /* Domain Name System (DNS) */
+#define PT_MPLSETHNOCW 21 /* MPLS PW Ethernet without Control Word */
#ifndef min
#define min(a,b) ((a)>(b)?(b):(a))
diff --git a/print-mpls.c b/print-mpls.c
index 62b79957..0c0ab974 100644
--- a/print-mpls.c
+++ b/print-mpls.c
@@ -50,7 +50,8 @@ enum mpls_packet_type {
PT_UNKNOWN,
PT_IPV4,
PT_IPV6,
- PT_OSI
+ PT_OSI,
+ PT_ETHER
};
/*
@@ -133,52 +134,68 @@ mpls_print(netdissect_options *ndo, const u_char *bp,
u_int length)
/* nothing to print */
return;
}
- switch(GET_U_1(p)) {
-
- case 0x45:
- case 0x46:
- case 0x47:
- case 0x48:
- case 0x49:
- case 0x4a:
- case 0x4b:
- case 0x4c:
- case 0x4d:
- case 0x4e:
- case 0x4f:
- pt = PT_IPV4;
- break;
-
- case 0x60:
- case 0x61:
- case 0x62:
- case 0x63:
- case 0x64:
- case 0x65:
- case 0x66:
- case 0x67:
- case 0x68:
- case 0x69:
- case 0x6a:
- case 0x6b:
- case 0x6c:
- case 0x6d:
- case 0x6e:
- case 0x6f:
- pt = PT_IPV6;
- break;
-
- case 0x81:
- case 0x82:
- case 0x83:
- pt = PT_OSI;
- break;
-
- default:
- /* ok bail out - we did not figure out what it is*/
- break;
+ if (ndo->ndo_packettype == PT_MPLSETHNOCW)
+ pt = PT_ETHER;
+ else
+ switch(GET_U_1(p)) {
+
+ case 0x45:
+ case 0x46:
+ case 0x47:
+ case 0x48:
+ case 0x49:
+ case 0x4a:
+ case 0x4b:
+ case 0x4c:
+ case 0x4d:
+ case 0x4e:
+ case 0x4f:
+ pt = PT_IPV4;
+ break;
+
+ case 0x60:
+ case 0x61:
+ case 0x62:
+ case 0x63:
+ case 0x64:
+ case 0x65:
+ case 0x66:
+ case 0x67:
+ case 0x68:
+ case 0x69:
+ case 0x6a:
+ case 0x6b:
+ case 0x6c:
+ case 0x6d:
+ case 0x6e:
+ case 0x6f:
+ pt = PT_IPV6;
+ break;
+
+ case 0x81:
+ case 0x82:
+ case 0x83:
+ pt = PT_OSI;
+ break;
+
+ case 0x00: /* RFC 4448 PW Ethernet Control Word */
+ if (ndo->ndo_vflag) {
+ ND_PRINT("\n\tPW Ethernet Control
Word");
+ p += 2;
+ ND_PRINT(", Sequence Number %u",
GET_BE_U_2(p));
+
Re: [tcpdump-workers] decode MPLS-contained packets?
--- Begin Message --- On 05/05/2020 21:44, Gert Doering wrote: >> We should print "PW Ethernet Control Word" and the "Sequence Number", 2 last >> 2 octets of the 4. >> Like: >> PW Ethernet Control Word, Sequence Number xxx > I think we should only print this if "-v" is given. Most of the time, > both control word and sequence number are of little interest. > > I really like tcpdump's very compact "only the most relevant info" output > format (by default). OK for "-v" only print. Other information from Francesco Fondelli: --- it is a bit more complicated than that, look for /* * No, there isn't, so use the 1st nibble logic (see BCP 4928, * RFC 4385 and 5586). */ in https://code.wireshark.org/review/gitweb?p=wireshark.git;a=blob;f=epan/dissectors/packet-mpls.c;h=4ecb10d1216077b92e6d4ca2520340cf053414f4;hb=HEAD and also the PW ETH heuristic in looks_like_plain_eth https://code.wireshark.org/review/gitweb?p=wireshark.git;a=blob;f=epan/dissectors/packet-pw-eth.c;h=aec7b662d38ddb36514ed3c213df47ad53ad610b;hb=HEAD Wireshark MPLS heuristic is not perfect and has been criticized but is still there :-) hopefully correctly parsing your data as well. For tcpdump maybe a -T based approach is better? -T mpls (+ 1st nibble logic for IPv4/IPv6) -T ethpw -T ethpwnocw ... --- Probably some more work to do... And probably linked to https://tools.ietf.org/html/rfc8469. -- Francois-Xavier --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] decode MPLS-contained packets?
--- Begin Message ---
On 05/05/2020 20:45, Francois-Xavier Le Bail via tcpdump-workers wrote:
> We should print "PW Ethernet Control Word" and the "Sequence Number", 2 last
> 2 octets of the 4.
> Like:
> PW Ethernet Control Word, Sequence Number xxx
Attached patch based on yours.
--
Francois-Xavier
diff --git a/print-mpls.c b/print-mpls.c
index 62b79957..e375c84a 100644
--- a/print-mpls.c
+++ b/print-mpls.c
@@ -50,7 +50,8 @@ enum mpls_packet_type {
PT_UNKNOWN,
PT_IPV4,
PT_IPV6,
- PT_OSI
+ PT_OSI,
+ PT_ETHER
};
/*
@@ -174,6 +175,15 @@ mpls_print(netdissect_options *ndo, const u_char *bp,
u_int length)
pt = PT_OSI;
break;
+ case 0x00: /* RFC 4448 PW Ethernet Control Word */
+ ND_PRINT("\n\tPW Ethernet Control Word");
+ p += 2;
+ ND_PRINT(", Sequence Number %u", GET_BE_U_2(p));
+ p += 2;
+ length -= 4;
+ pt = PT_ETHER;
+ break;
+
default:
/* ok bail out - we did not figure out what it is*/
break;
@@ -203,6 +213,10 @@ mpls_print(netdissect_options *ndo, const u_char *bp,
u_int length)
isoclns_print(ndo, p, length);
break;
+ case PT_ETHER:
+ ether_print(ndo, p, length, ND_BYTES_AVAILABLE_AFTER(bp), NULL,
NULL);
+ break;
+
default:
break;
}
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] decode MPLS-contained packets?
--- Begin Message ---
On 05/05/2020 20:37, Gert Doering wrote:
> Hi,
>
> On Tue, May 05, 2020 at 07:28:28PM +0200, Francois-Xavier Le Bail wrote:
>> On 05/05/2020 12:15, Gert Doering via tcpdump-workers wrote:
>>> In my case, there is an MPLS control word before the ethernet header
>>> (" "), and if I skip that and just clear "ethernet in here", I
>>> get nicely printed packets...
>>
>> It seems it is like:
>> https://tools.ietf.org/html/rfc4448#section-4.6
>>
>> Can you confirm?
>
> This very much looks like it, indeed.
>
> 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 skip 4 bytes
> and the rest is a regular Ethernet packet" should work.
We should print "PW Ethernet Control Word" and the "Sequence Number", 2 last 2
octets of the 4.
Like:
PW Ethernet Control Word, Sequence Number xxx
[...]
18:31:01.221109 00:22:55:93:74:80 > a8:0c:0d:56:50:3b, ethertype MPLS unicast
(0x8847), length 140:
MPLS (label 24002, exp 0, [S], ttl 253)
PW Ethernet Control Word, Sequence Number 0
00:c1:64:65:92:0f > 3c:fd:fe:bd:78:35, ethertype IPv4 (0x0800)
[...]
--
Francois-Xavier
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] decode MPLS-contained packets?
--- Begin Message ---
On 05/05/2020 12:15, Gert Doering via tcpdump-workers wrote:
> In my case, there is an MPLS control word before the ethernet header
> (" "), and if I skip that and just clear "ethernet in here", I
> get nicely printed packets...
It seems it is like:
https://tools.ietf.org/html/rfc4448#section-4.6
Can you confirm?
--
Francois-Xavier
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] decode MPLS-contained packets?
--- Begin Message --- On 05/05/2020 19:17, Gert Doering wrote: > Hi, > > On Tue, May 05, 2020 at 06:45:27PM +0200, Francois-Xavier Le Bail wrote: >>> Attached as well. Not very smart yet, just does "what I need". >> >> Thanks, >> >> Patch for which tcpdump version? > > github checkout, it identifies itself as > > tcpdump version 4.10.0-PRE-GIT > > (git clone https://github.com/the-tcpdump-group/tcpdump.git) Ok, it had DOS line ending format ... --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] decode MPLS-contained packets?
--- Begin Message --- On 05/05/2020 18:34, Gert Doering wrote: > Hi, > > On Tue, May 05, 2020 at 04:45:04PM +0200, Francois-Xavier Le Bail wrote: >> On 05/05/2020 12:15, Gert Doering via tcpdump-workers wrote: >>> 12:11:46.116238 MPLS (label 105, exp 0, ttl 254) (label 24003, exp 0, [S], >>> ttl 254) IP 10.27.99.2 > 10.27.99.34: ICMP echo request, id 49866, seq >>> 5160, length 84 >>> 12:11:46.117107 MPLS (label 24002, exp 0, [S], ttl 253) IP 10.27.99.34 > >>> 10.27.99.2: ICMP echo reply, id 49866, seq 5160, length 84 >>> >>> >>> So, for my debugging purposes, I have what I need now. >> >> [...] > >> And the patch you apply ? > > Attached as well. Not very smart yet, just does "what I need". Thanks, Patch for which tcpdump version? -- Francois-Xavier --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] decode MPLS-contained packets?
--- Begin Message --- On 05/05/2020 12:15, Gert Doering via tcpdump-workers wrote: > 12:11:46.116238 MPLS (label 105, exp 0, ttl 254) (label 24003, exp 0, [S], > ttl 254) IP 10.27.99.2 > 10.27.99.34: ICMP echo request, id 49866, seq 5160, > length 84 > 12:11:46.117107 MPLS (label 24002, exp 0, [S], ttl 253) IP 10.27.99.34 > > 10.27.99.2: ICMP echo reply, id 49866, seq 5160, length 84 > > > So, for my debugging purposes, I have what I need now. Could you send a pcap file with the ICMP echo request/reply test ? And the patch you apply ? -- Francois-Xavier --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Compile libpcap with DLT_LINUX_SLL2
--- Begin Message --- 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 ffb99eceefd31771a4aa89f0da5d02a3c53cfd03. > Thanks a lot! > > BTW how about DLT_LINUX_SLL2 as the default? What does it block? To avoid breaking program that cannot use SLL2, could we have an API like pcap_set_cooked_default_ssl2() or pcap_set_default_ssl2_on_any() and use it in tcpdump? -- Francois-Xavier --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] Fwd: Re: [tcpdump] About smiInit() parameter
--- Begin Message ---
Forwarded Message
Subject: Re: [tcpdump] About smiInit() parameter
On 30/03/2020 19:54, Guy Harris wrote:
>
>> 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 something else to separate the lib and the tool ?
>
> The man page at
>
> https://www.ibr.cs.tu-bs.de/projects/libsmi/smi_config.html
>
> [...]
>
> I don't know if anybody's actually *using* that particular libsmi feature,
> but smiInit has been called with "tcpdump" as an argument since at least
> tcpdump 0.7. For what it's worth, the configuration file example they give
> in the man page *does* have a "tcpdump:" statement in it:
>
> Example configuration:
> [...]
>
>tcpdump: load DISMAN-SCRIPT-MIB
>
> so there might be some who have "tcpdump:" statements in libsmi configuration
> files.
Yes, good point.
> So either
>
> 1) we should consider leaving "tcpdump" there
Yes.
> 2) we should make the tag an argument to nd_init and pass it "tcpdump"
> from tcpdump
>
> although the latter means that any new program using libnetdissect might
> dissect SNMP packets differently from tcpdump, whether that's a bug or a
> feature.
Because the choice is difficult here.
If someone complain in the list or in an issue, we could consider an update.
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Compile libpcap with DLT_LINUX_SLL2
--- Begin Message --- On 13/03/2020 12:35, Bill Fenner via tcpdump-workers wrote: > > The "-y" flag to tcpdump allows you to specify capturing with > DLT_LINUX_SLL2. Should DLT_LINUX_SLL2 be now the default when tcpdump is built with a libpcap that support it ? -- Francois-Xavier --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] New RFCs for 1) pcap file format and 2) rpcapd protocol?
--- Begin Message --- 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 under the pcapng team as per the same > reason as 4). Ok. --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] New RFCs for 1) pcap file format and 2) rpcapd protocol?
--- Begin Message --- On 21/03/2020 22:14, Guy Harris via tcpdump-workers wrote: > 1) has the slight disadvantage that the name for the team suggests it's for > pcapng only; it appears that teams can be renamed: > > > https://help.github.com/en/github/setting-up-and-managing-organizations-and-teams/renaming-a-team > > Were we to rename it, I don't know what would be a good new name. Option 1) with a rename to pcapteam or pcapXteam? --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] [the-tcpdump-group/libpcap] Use tab instead of space in formatting pcap-int.h (#918)
--- Begin Message --- On 19/03/2020 22:11, Michael Richardson via tcpdump-workers wrote: > I will submit a whitespace change to master next week, and then a modeline > fix. > Are there any integrations to github that will warn people to fix their > whitespace settings? Could you explain the whitespace change you are thinking? -- Francois-Xavier --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] [the-tcpdump-group/libpcap] Use tab instead of space in formatting pcap-int.h (#918)
--- Begin Message --- On 20/03/2020 16:16, Michael Richardson wrote: > Francois-Xavier Le Bail wrote: > >> > If we do, we should replace all the tabs in pcap-int.h with spaces; > we > >> > should at least be consistent, and change #918 fixed one inconsistent > >> > case. > >> > >> Let's agree that we are going towards spaces. > >> I think most files are using 8-space indents, a la Linux Kernel. > > > Where is the beginning of this discussion ? > > In a github ticket, #918. I don't see the message starting this conversation in #918, nor the following ones. Could you push them in the list? -- Francois-Xavier --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] [the-tcpdump-group/libpcap] Use tab instead of space in formatting pcap-int.h (#918)
--- Begin Message --- On 19/03/2020 22:11, Michael Richardson via tcpdump-workers wrote: > >> I thought we wanted all spaces? > > > If we do, we should replace all the tabs in pcap-int.h with spaces; we > > should at least be consistent, and change #918 fixed one inconsistent > > case. > > Let's agree that we are going towards spaces. > I think most files are using 8-space indents, a la Linux Kernel. Where is the beginning of this discussion ? -- Francois-Xavier --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] tcpdump testsuite and Perl
--- Begin Message --- On 03/02/2020 03:17, Guy Harris wrote: >> And remove the yaml stuff. > ...which, it appears, is not being used; we're still using the old plain-text > TESTLIST file, and have no YAML files for tests yet. > > What YAML would provide would be easier extensibility, in that you can just > add another key if you need another per-test value. The question is whether > that's worth adding a dependency or not. I like the #821 PR. It provides extensibility without YAML. -- Francois-Xavier --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] tcpdump testsuite and Perl
--- Begin Message --- On 02/02/2020 04:24, Francois-Xavier Le Bail wrote: > On 31/01/2020 17:19, Michael Richardson wrote: >> >> Francois-Xavier Le Bail via tcpdump-workers wrote: >> > On 28/01/2020 23:17, Denis Ovsienko via tcpdump-workers wrote: >> >> The new dependency makes it more difficult to run tests and will break >> >> package builds downstream (thus penalising people that cared enough to >> >> make "make check" a part of the build). Maybe the cost of the solution >> >> does not justify the problem it solves (which it would be nice to >> >> state)? >> >> > Why not just keep the TESTLIST file as it is, a text file with test >> lines and comments? >> >> Because it does not live alone actually. >> >> It has a series of foo.sh files do that do annoying testing based upon what >> is configured, and I'd like to do more of the process of testing things that >> are configured, or when they are not configured. >> I don't want to write more shell scripts. > > We could add a "type" field in TESTLIST and do the process following this > type. > > std: standard test. > crypto: need ssl library. > gcc: need GCC compiler. > etc. > > Like in: > https://github.com/the-tcpdump-group/tcpdump/commit/745cd41b98feff4228783501be37889f7a473e5b > (test branch: typed-tests) Typo fixed in: https://github.com/the-tcpdump-group/tcpdump/commit/23848a19458970c4127d5a0364f690767362c3b6 (This is just a first step for showing the idea, the 'crypto' and 'gcc' tests could be move in TESTLIST for a processing based on the field 'type') -- Francois-Xavier --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] tcpdump testsuite and Perl
--- Begin Message --- On 02/02/2020 04:24, Francois-Xavier Le Bail via tcpdump-workers wrote: > We could add a "type" field in TESTLIST and do the process following this > type. > > std: standard test. > crypto: need ssl library. > gcc: need GCC compiler. > etc. > > Like in: > https://github.com/the-tcpdump-group/tcpdump/commit/745cd41b98feff4228783501be37889f7a473e5b > (test branch: typed-tests) And remove the yaml stuff. -- Francois-Xavier --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] tcpdump testsuite and Perl
--- Begin Message --- On 31/01/2020 17:19, Michael Richardson wrote: > > Francois-Xavier Le Bail via tcpdump-workers wrote: > > On 28/01/2020 23:17, Denis Ovsienko via tcpdump-workers wrote: > >> The new dependency makes it more difficult to run tests and will break > >> package builds downstream (thus penalising people that cared enough to > >> make "make check" a part of the build). Maybe the cost of the solution > >> does not justify the problem it solves (which it would be nice to > >> state)? > > > Why not just keep the TESTLIST file as it is, a text file with test > lines and comments? > > Because it does not live alone actually. > > It has a series of foo.sh files do that do annoying testing based upon what > is configured, and I'd like to do more of the process of testing things that > are configured, or when they are not configured. > I don't want to write more shell scripts. We could add a "type" field in TESTLIST and do the process following this type. std: standard test. crypto: need ssl library. gcc: need GCC compiler. etc. Like in: https://github.com/the-tcpdump-group/tcpdump/commit/745cd41b98feff4228783501be37889f7a473e5b (test branch: typed-tests) -- Francois-Xavier --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] tcpdump testsuite and Perl
--- Begin Message --- On 28/01/2020 23:17, Denis Ovsienko via tcpdump-workers wrote: > The new dependency makes it more difficult to run tests and will break > package builds downstream (thus penalising people that cared enough to > make "make check" a part of the build). Maybe the cost of the solution > does not justify the problem it solves (which it would be nice to > state)? Why not just keep the TESTLIST file as it is, a text file with test lines and comments? -- Francois-Xavier --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] tcpdump testsuite and Perl
--- Begin Message --- On 28/01/2020 18:45, Michael Richardson wrote: > > Francois-Xavier Le Bail wrote: > >> I noticed that the testsuite of tcpdump recently fails with > >> "make_path" is not exported by the File::Path module > >> "remove_tree" is not exported by the File::Path module > >> Can't continue after import errors at ./tests/TESTrun line 8 > >> BEGIN failed--compilation aborted at ./tests/TESTrun line 8. > >> as can bee seen in the log at > >> > https://buildfarm.opencsw.org/buildbot/builders/tcpdump-solaris10-amd64/builds/2960/steps/shell_3/logs/stdio > >> > >> This is because the system Perl on Solaris 10 is Perl 5.8.4 which uses > >> the slighly different mkpath and rmtree > >> https://perldoc.perl.org/5.8.4/File/Path.html > > okay. > > >> > >> Even in recent Perl 5.30 the legacy functions mkpath and rmtree are > still in: > >> https://perldoc.perl.org/File/Path.html > > So if I use "mkpath" (I actually don't need "rmtree" yet), then I'll be good > across all versions? > > I have done this now. Currently on OpenCSW Solaris 10: "./tests/TESTrun TESTrun needs YAML.pm. apt install libyaml-perl/yum install per-YAML/cpanm YAML at ./tests/TESTrun line 10. gmake: *** [Makefile:448: check] Error 2" Missing package? -- Francois-Xavier --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
