--- 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
--- 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
>
--- 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
>
[Send, second try]
On 02/03/2023 09:22, Francois-Xavier Le Bail wrote:
> On 01/03/2023 20:28, Denis Ovsienko wrote:
>> On Tue, 28 Feb 2023 17:01:51 +0100
>> Francois-Xavier Le Bail wrote:
>>
>>> In addition to printf()/fprintf(), here is a brand new way to help
On 02/03/2023 09:22, Francois-Xavier Le Bail wrote:
> On 01/03/2023 20:28, Denis Ovsienko wrote:
>> On Tue, 28 Feb 2023 17:01:51 +0100
>> Francois-Xavier Le Bail wrote:
>>
>>> In addition to printf()/fprintf(), here is a brand new way to help
>>> debugging
On 22/09/2023 09:02, Francois-Xavier Le Bail wrote:
>> In 2005, a patch was proposed about TSO (TCP segment offload) for print-ip.c
>> with a "#ifdef GUESS_TSO".
>> https://github.com/the-tcpdump-group/tcpdump/commit/c8623960f050cb81c12b31107070021f27f14b18
>>
On 04/10/2023 08:39, Francois-Xavier Le Bail wrote:
> Hello,
>
> Reviews and comments welcome on PR 980.
> (Answer on PR page.)
>
> https://github.com/the-tcpdump-group/libpcap/pull/980
In subject s/[tcpdump]/[libpcap]/
___
tcpdu
Hello,
Reviews and comments welcome on PR 980.
(Answer on PR page.)
https://github.com/the-tcpdump-group/libpcap/pull/980
--
Francois-Xavier
___
tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org
To unsubscribe send an email to
> In 2005, a patch was proposed about TSO (TCP segment offload) for print-ip.c
> with a "#ifdef GUESS_TSO".
> https://github.com/the-tcpdump-group/tcpdump/commit/c8623960f050cb81c12b31107070021f27f14b18
>
> It was never build by default. Is there a reason? Missing tests? Missing some
>
Hello,
In 2005, a patch was proposed about TSO (TCP segment offload) for print-ip.c
with a "#ifdef GUESS_TSO".
https://github.com/the-tcpdump-group/tcpdump/commit/c8623960f050cb81c12b31107070021f27f14b18
It was never build by default. Is there a reason? Missing tests? Missing some
additional
On 29/08/2023 16:34, Scheffenegger, Richard via tcpdump-workers wrote:
> And some initial discussions which aren't yet reflected on the mailing list:
>
> -Original Message-
> From: Scheffenegger, Richard
> Sent: Freitag, 18. August 2023 14:01
> To: Francois-Xavier Le
On 22/08/2023 20:41, Michael Richardson wrote:
>
> Francois-Xavier Le Bail wrote:
> > Does anyone see a problem with this change? (Answer on PR page.)
>
> > https://github.com/the-tcpdump-group/tcpdump/pull/812
>
> It looks so simple, it's probably correct
Hello,
Does anyone see a problem with this change?
(Answer on PR page.)
https://github.com/the-tcpdump-group/tcpdump/pull/812
Greetings,
--
Francois-Xavier
___
tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org
To unsubscribe send an
Hello,
Does anyone see a problem with this change?
(Answer on PR page.)
https://github.com/the-tcpdump-group/tcpdump/pull/1043
--
Francois-Xavier
___
tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org
To unsubscribe send an email to
On 13/04/2023 09:46, Francois-Xavier Le Bail wrote:
> Hello,
>
> Does anyone see a problem with this change?
> (Answer on PR page.)
>
> https://github.com/the-tcpdump-group/tcpdump/pull/972
The PR has been merged.
___
tcpdump-wo
Hello,
Does anyone see a problem with this change?
(Answer on PR page.)
https://github.com/the-tcpdump-group/tcpdump/pull/972
--
Francois-Xavier
___
tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org
To unsubscribe send an email to
On 28/02/2023 17:01, Francois-Xavier Le Bail wrote:
> On 20/02/2023 21:18, Guy Harris wrote:
>> On Feb 20, 2023, at 12:15 PM, Paschal Chukwuebuk Amusuo
>> wrote:
>>
>>> Please, is there a way to print out debug statements at runtime when using
>>> pcap?
On 01/03/2023 20:28, Denis Ovsienko wrote:
> On Tue, 28 Feb 2023 17:01:51 +0100
> Francois-Xavier Le Bail wrote:
>
>> In addition to printf()/fprintf(), here is a brand new way to help
>> debugging a program using libpcap, currently only tested on Debian
>> Linux (sta
On 20/02/2023 21:18, Guy Harris wrote:
> On Feb 20, 2023, at 12:15 PM, Paschal Chukwuebuk Amusuo
> wrote:
>
>> Please, is there a way to print out debug statements at runtime when using
>> pcap?
>
> Debug statements in your program? Add printf() or fprintf(stderr, ...) or...
> calls to your
On 26/02/2023 22:45, Denis Ovsienko wrote:
> On Sun, 26 Feb 2023 15:46:56 +0100
> Francois-Xavier Le Bail wrote:
>
> [...]
>>>> I wonder if there would be any other incurred future maintenance.
>>
>> The proposed patch is:
>>
>> diff --git a
On 19/02/2023 13:34, Francois-Xavier Le Bail wrote:
> On 18/02/2023 21:51, Denis Ovsienko wrote:
>> On Sat, 18 Feb 2023 17:06:29 +0100
>> Francois-Xavier Le Bail wrote:
>>
>>> Hello,
>>>
>>> https://www.rfc-editor.org/rfc/rfc9293 states:
>>
On 19/02/2023 13:34, Francois-Xavier Le Bail wrote:
> On 18/02/2023 21:51, Denis Ovsienko wrote:
>> On Sat, 18 Feb 2023 17:06:29 +0100
>> Francois-Xavier Le Bail wrote:
>>
>>> Hello,
>>>
>>> https://www.rfc-editor.org/rfc/rfc9293 states:
>>
On 18/02/2023 21:51, Denis Ovsienko wrote:
> On Sat, 18 Feb 2023 17:06:29 +0100
> Francois-Xavier Le Bail wrote:
>
>> Hello,
>>
>> https://www.rfc-editor.org/rfc/rfc9293 states:
>> "Control bits:
>>
>> The control bits are also known as "
Hello,
https://www.rfc-editor.org/rfc/rfc9293 states:
"Control bits:
The control bits are also known as "flags". Assignment is managed by IANA
from the "TCP Header Flags" registry [62]. The currently assigned control bits
are CWR, ECE, URG, ACK, PSH, RST, SYN, and FIN."
(All on three
--- 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
--- 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
--- 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
--- 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 whic
--- 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
--- 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
--- 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 ---
--- 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,
>
--- 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;
--- 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
>
--- 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
--- 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
>>
--- 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?
--- 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://opensour
--- 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
--- 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
--- 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
--- 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 doin
--- 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
--- 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
>
--- 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 s
--- 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
--- 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;
&g
--- 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
--- 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
--- 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:
>>
>>>
--- 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;
>&
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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 t
--- 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
--- 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?
>
--- 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
--- 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 pr
--- 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
--- 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
--- 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, coul
--- 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 w
--- 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_
--- 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 li
--- 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
--- 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 ---
--- 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
--- 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 th
--- 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,
--- 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 pat
--- 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 et
--- 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:
--- 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,
>>
>> P
--- 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 240
--- 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,
--- 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
--- 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:
>>
--- 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
--- 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 ---
--- 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:
>
>
>
--- 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
--- 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 on
--- 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
> >
--- 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
--- 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:
>> >&
--- 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 co
--- 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 b
--- 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
--- 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
> >> &quo
On 03/05/2019 19:08, Guy Harris wrote:
> Commit e150c713a2ea333e9ab173e062b447dd65c9a4ee added some ND_TCHECK_LEN()
> calls before doing a memcpy.
>
> Should we have a function
>
> static inline void
> get_bytes(netdissect_options *ndo, u_char *dst, const u_char *p, size_t
> len)
>
On 19/08/2019 03:48, Michael Richardson wrote:
>
> Francois-Xavier Le Bail wrote:
> >> We build with gcc and clang on travis, with options that do not always
> match
> >> what contributors get by default.
> >>
> >> I've added "
On 18/08/2019 19:49, Michael Richardson wrote:
> We build with gcc and clang on travis, with options that do not always match
> what contributors get by default.
>
> I've added "./buildem" which goes through the set of -m32/-m64 and clang, gcc
> to build them all using build directories.
> It
On 03/05/2019 19:08, Guy Harris wrote:
> Should we have a function
>
> static inline void
> get_bytes(netdissect_options *ndo, u_char *dst, const u_char *p, size_t
> len)
> {
> if (!ND_TCHECK_LEN(p, len))
> longjmp(ndo->ndo_truncated, 1);
>
On 16/04/2019 17:14, Francois-Xavier Le Bail wrote:
> 39 printers are missing in win32/prj/GNUmakefile. Someone use it ? keep it ?
If no one uses it, we will delete it.
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
ht
Hi,
39 printers are missing in win32/prj/GNUmakefile. Someone use it ? keep it ?
--
Francois-Xavier
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[not seen on the list, sent again]
Hello,
Denis had removed a useless warning about the SMB decoder.
(commit 415b70b6cedadb4a08b7e873385226f0a7b68076)
Is it time to remove --enable-smb/--disable-smb (enable possibly-buggy SMB
printer) code ?
--
Francois-Xavier
On 21/08/2018 17:21, Denis Ovsienko wrote:
> (moving this to tcpdump-workers)
>
> On Tue, 08 May 2018 14:41:13 +0100 Francois-Xavier Le Bail
> wrote
> > e.g.:
> > proto1_print(...)
> > {
> > ndo->ndo_protocol = &qu
1 - 100 of 139 matches
Mail list logo
