On Oct 7, 2019, at 11:07 AM, Mario Rugiero wrote:
>> So that would mean using non-memory-mapped capturing in immediate mode.
>> That might even work better for that purpose - yes, there's more copying
>> involved (copying the packet to the socket buffer and then copying from the
>> socket buf
On Oct 7, 2019, at 12:55 PM, Mario Rugiero wrote:
> El lun., 7 oct. 2019 a las 16:07, Guy Harris () escribió:
>
>> So are you saying that, even if you're using libpcap to implement a protocol
>> running directly atop the link layer, rather than passively sniffing
>
On Oct 7, 2019, at 11:29 AM, Guy Harris wrote:
> While we're discussing dropping support for older OSes:
>
> Do we still need to worry about:
sufficiently old versions of macOS (only 10.5 and later? only 10.6 and
later? only
On Oct 8, 2019, at 9:29 AM, Mario Rugiero wrote:
> Supporting TPACKET_V2 should suffice to fill this gap, right?
> We would still need to make a few changes, currently you need to use a
> kernel which doesn't support TPACKET_V3 to use this correctly.
> It shouldn't be a big change to make immedia
On Oct 8, 2019, at 8:43 AM, Michael Richardson wrote:
> And that's why I think we would agree that we don't want to let tcpdump go
> all C99, etc. yet, because people often *do* want the latest tcpdump, on top
> of a kernel-compatible libpcap.
What do you mean by "all C99"? The master branch's
On Oct 8, 2019, at 2:15 PM, Michael Richardson wrote:
> I don't really know which "legacy" compiler stuff that we may wish to
> continue to tolerate in tcpdump, but which we can dispense with in libpcap.
At this point, in the master branch, I'm not sure there's a difference between
how much C99
On Oct 14, 2019, at 9:55 AM, Nick Kelsey wrote:
> ATSC 3.0 includes a new link layer protocol known as ALP (ATSC Link-layer
> protocol).
>
> A linktype allocation would enable packet capture and diagnostics of the ATSC
> 3.0 link layer.
>
> Proposed linktype allocation:
>
> LINKTYPE_ name =
On Oct 14, 2019, at 12:10 PM, Nick Kelsey wrote:
>>> ATSC 3.0 includes a new link layer protocol known as ALP (ATSC Link-layer
>>> protocol).
>
>> So the first two octets of the packet data contain the Base Header?
>> That appears to be a 16-bit header; in a capture, in what order are the
>>
On Feb 18, 2023, at 10:27 AM, Denis Ovsienko wrote:
> OS IPv6 support would be a very reasonable requirement for tcpdump 5.
Which would, among other things, let us remove the tests for various add-on
IPv6 stacks in configure.ac.
___
tcpdump-workers ma
On Feb 20, 2023, at 12:17 AM, Denis Ovsienko wrote:
> AF_INET6 looks a bit more convoluted. There is some code that uses
> AF_INET6 to dissect wire encoding, which is usually a wrong idea. For
> example, pimv2_addr_print() switches on AF_INET and AF_INET6, and the
> PIMv2 header encoding (RFC 4
On Feb 20, 2023, at 2:20 AM, Guy Harris wrote:
> So the code is correct, but could easily be misintrpreted. Perhaps it'd be
> better if we used the values from af.h rather than using AF_INET and
> AF_INET6.
Done in 0dc32a024773968cb1ae00729758e61b7418564a
I'll see wh
On Feb 20, 2023, at 12:15 PM, Paschal Chukwuebuk Amusuo
wrote:
> Please, is there a way to print out debug statements at runtime when using
> pcap?
Debug statements in your program? Add printf() or fprintf(stderr, ...) or...
calls to your program.
Debug statements in libpcap? Get the libpc
On May 7, 2023, at 9:27 AM, Michael Richardson wrote:
> Frederick Virchanza Gotham wrote:
>> I think that there should be a page in the libpcap manual that
>> explicitly explains the multithreading capabilities and limitations.
>
> okay, that sounds reasonable.
> git clone https://github.com/t
Testing to see whether subscribing worked.
___
tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org
To unsubscribe send an email to tcpdump-workers-le...@lists.tcpdump.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
Another test of subscribing via the Web
___
tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org
To unsubscribe send an email to tcpdump-workers-le...@lists.tcpdump.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
The MS-DOS support in libpcap was recently removed in the main branch; the
comment for the pull request is "MSDOS packet driver interface is no longer
testable", and the comment for the first commit is "MSDOS packet driver
interface is no longer testable, anyone needs it can use a previous versi
On Mar 8, 2021, at 12:07 AM, Jan Adam via tcpdump-workers
wrote:
> We have created a public document on our website You can point to for the
> description.
>
> Here is the link: https://kb.hilscher.com/x/brDJBw
>
> It contains a more detailed description of the fields in the footer structure
Is the list working?
___
tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org
To unsubscribe send an email to tcpdump-workers-le...@lists.tcpdump.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
On Feb 5, 2024, at 9:38 AM, Bill Fenner wrote:
> Is this a reasonable way to proceed?
Yes.
Perhaps have a file icmp-common.c or print-icmp-common.c with code and data
structures common to ICMP(v4) and ICMPv6?
___
tcpdump-workers mailing list -- tcpdu
On Mar 12, 2024, at 2:07 PM, Rick Jones via tcpdump-workers
wrote:
> If https://en.wikipedia.org/wiki/HP-UX#Version_history is any indication,
> there are ~21 months left on HP's (er, sorry, HPE's) own support for HP-UX.
As far as I know, now that Itania are no longer being manufactured and shi
On Mar 28, 2024, at 3:01 AM, Denis Ovsienko wrote:
> There is a rather old pull request at [1], which was supposed to make
> use of the then-unused SIGUSR2, but whilst it was waiting, another pull
> request used the signal for another code path.
>
> There is a potential way to manage this kind o
On Mar 28, 2024, at 2:19 PM, Denis Ovsienko wrote:
> Yes, AIX and Haiku sometimes make portability issues manifest.
And, in this case, Solaris doesn't have SIGINFO, either; SunOS 0.x-4.x didn't
have it, as BSD hadn't picked it up, and they didn't pass it along to be put
into SVR4, so it's not
On Apr 1, 2024, at 6:53 AM, Michael Richardson wrote:
> I wonder if we should nuke our own make tarball system.
I.e., replace:
to get {libpcap,tcpdump,tcpslice} version X.Y.Z, download
{libpcap,tcpdump,tcpslice}-X.Y.Z.tar.{compression-suffix}
with
to get {libpcap,tcpdump,tcps
A while ago, tcpdump and its configuration script were modified - mainly by
Bill Fenner, as I remember - so that it didn't require a contemporary version
of libpcap, and could be built with older versions of libpcap.
The intent, as I remember, was to allow somebody who was using a system that
p
On Apr 15, 2024, at 3:47 PM, Ravi chandra wrote:
> I am planning to create an ieee 802.11 packet RadioTap parsing
> code/library [offlines processing of pcap-ng files. Decoding each and
> every field and write it to a .csv file].
If that's all you're doing, is there some reason why you don't jus
On Apr 19, 2024, at 5:49 AM, Denis Ovsienko wrote:
> On Fri, 12 Apr 2024 18:49:05 -0700
> Guy Harris wrote:
...
> Since tcpdump is the reference implementation of a program that uses
> libpcap, it may be a good occasion to improve the solution space such
> that other so
On Apr 29, 2024, at 7:19 AM, Michal Ruprich wrote:
> I was wondering, whether the mem[BPF_MEMWORDS] array in function
> pcapint_filter_with_aux_data in bpf_filter.c should be initialized? If the
> switch hits cases BPF_LD|BPF_MEM or BPF_LDX|BPF_MEM the variables A or X are
> filled with random
On May 10, 2024, at 1:39 PM, Denis Ovsienko wrote:
> I have been looking through commits and the 1.10.5 section of libpcap
> change log, and the recent changes to the link-layer header type field
> structure look like a potential place for things to go wrong.
>
> Specifically, the new prose says
On Apr 12, 2024, at 6:49 PM, Guy Harris wrote:
> Is there any reason not to require libpcap 1.0 or later? If there is, is
> there any reason not to require libpcap 0.7 or later?
OK, support removed, in the main branch. for libpcaps with only pre-1.0 APIs.
The 4.99 branch still support
On May 20, 2024, at 8:31 AM, luoyuxuan.c...@gmail.com wrote:
>I've noticed that the question about libpcap's support for writing files
> in the pcapng format has been brought up multiple times in the mailing list.
> Yet, I'm still curious about the current status of this function. Can anyone
On May 20, 2024, at 9:56 AM, Michael Richardson wrote:
>> implementation under the APSL license, I wonder if the community is
>> allowed to submit a pull request for it. Are there any restrictions or
>> guidelines we should be aware of in this regard? Thanks for your time
>> and patience.
>
> M
obvious issue
caused by 1), two issues caused by 2) also appeared, one of which occurred with
*BSD (including CupertinoBSD, a/k/a Darwin) servers, and another of which
occurred only between Solaris and non-Solaris platforms.
The fix for these issues was
commit 6ee13e223c9709e79ac112f8c37ff0a72
> On Oct 20, 2024, at 12:11 AM, Garri Djavadyan wrote:
>
> On Sat, 2024-10-19 at 23:58 -0700, Guy Harris wrote:
>> On Oct 19, 2024, at 5:01 PM, Garri Djavadyan
>> wrote:
>>
>>> I am looking for a way to force tcpdump flush Linux OS buffer
>>> b
On Oct 19, 2024, at 5:01 PM, Garri Djavadyan wrote:
> I am looking for a way to force tcpdump flush Linux OS buffer before
> terminating. I have checked the man page and the mailing list archives
> but did not manage to find anything related.
>
> When I terminate tcpdump process with SIGINT or S
On Oct 20, 2024, at 2:57 AM, Garri Djavadyan wrote:
>>> I have to use a very big buffer with a very slow storage, much
>>> slower
>>> than the rate of coming packets received by the filter, and it is
>>> preferred not to lose a single packet after initiating termination
>>> the
>>> process.
>>
>
On Jun 10, 2024, at 12:39 PM, Alberto Perez Bogantes via tcpdump-workers
wrote:
> We've been working on adding a new feature to tcpdump that will allow IP
> address anonymization ...
...
>
> I am sharing my GitHub project (https://github.com/aperezb21/tcpdump),
> which is forked from commit b
ubu22-04$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=22.04
DISTRIB_CODENAME=jammy
DISTRIB_DESCRIPTION="Ubuntu 22.04.5 LTS"
ubu22-04$ ifconfig -a
ens33: flags=4163 mtu 1500
inet 172.16.135.246 netmask 255.255.255.0 broadcast 172.16.135.255
inet6 fe80::eee8:133e:43dd:47
On Oct 1, 2024, at 8:38 AM, Kaushal Shriyan wrote:
> Thanks, Michael, for the quick response. Is there a way to capture and
> analyze *HTTPS* traffic since the data is encrypted?
Maybe, *if* you can get the necessary information; see
https://wiki.wireshark.org/TLS#tls-decryption
As it
On Nov 18, 2024, at 12:15 PM, Michael Richardson wrote:
> Denis Ovsienko wrote:
>> One complication here is that in some cases libpcap may not be aware of
>> a device capability until it gets an error from the OS (as is the case
>> with PCAP_ERROR_CAPTURE_NOTSUP in pcap-linux.c), so pcap_findall
On Nov 18, 2024, at 9:08 AM, Michael Richardson wrote:
> The message about the spam was in fact spam.
So what is the purpose of those types of spam? Testing a list's spam detectors?
___
tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org
On Nov 18, 2024, at 11:54 AM, Denis Ovsienko wrote:
> The current approach in libpcap is such that an application at some
> point tries to activate a device, and if the device does not support
> capturing packets, pcap_activate() fails with the
> PCAP_ERROR_CAPTURE_NOTSUP error code. One drawbac
Bogus - the oldest Received: line is
Received: from wireshark.org (unknown [64.124.12.162])
by rivoli.gatineau.credil.org (Postfix) with ESMTP id 7C05A9EC
for ;
Sun, 17 Nov 2024 14:39:06 -0500 (EST)
and
$ host 64.124.12.162
162.12.124.64.in-addr.a
On Feb 12, 2025, at 1:54 PM, Francois-Xavier Le Bail via tcpdump-workers
wrote:
> They are also different:
>
> $ diff bpf_dump.c ../libpcap/bpf_dump.c
>
> 24,25c24
> < #include "netdissect-stdinc.h"
> <
> ---
> > #include
That's because the first one
On Feb 12, 2025, at 11:05 PM, Guy Harris wrote:
> Given that BDEBUG is a libpcap definition that affects a lot more things, my
> inclination would be to, if we keep tcpdump's bpf_dump.c, remove the BDEBUG
> stuff
...which Denis has done.
_
On Apr 6, 2025, at 2:28 PM, Michael Richardson wrote:
> Mahesh V wrote:
>> I added some code (modified) tcpdump to write the pcapng file.
>> while configuring/compiling the source code I get this error
>> This is a cross compilation for ARM platform
>
> Well, likely the resulting flex test can'
On Apr 8, 2025, at 7:13 AM, Mahesh V wrote:
> I dont have that information.
> Question remains, why does flex choose m4 binary that is compiled into it and
> not from the PATH (env variable)
> which m4 and which flex (both exist in the same path)
That's a good question.
I do not know the answ
On Apr 7, 2025, at 2:11 AM, Mahesh V wrote:
> Flex is not getting built. We have the binary checked in to our repository.
What process produced that binary? Is it a binary you compiled, is it a copy of
a binary from the OS, or is it from somewhere else?
_
On Apr 6, 2025, at 11:19 PM, Mahesh V wrote:
> configure:7921: checking for flex
> configure:7937: found tools/arm-5.3-uclibc-1.0.12/usr/bin/flex
> configure:7948: result: flex
> configure:7986: flex conftest.l
> flex: fatal internal error, exec of
> /var/tmp/tool-chains/buildroot-2016.02-5.3-ar
On Apr 4, 2025, at 10:22 AM, Mahesh V wrote:
> I would like to know if
> 1) tcpdump can write pcapng format (instead of just pcap)
Currently, no. tcpdump uses libpcap to read and write capture files, and
libpcap doesn't yet support writing pcapng.
> 2) Accept per packet comments from the kern
On Apr 4, 2025, at 11:29 AM, Michael Richardson wrote:
> I can't recall if we can read pcapng.
libpcap - and thus programs, such as tcpdump, that use libpcap to read capture
files - can read some pcapng files, as long as the current libpcap API can
handle them. That's been the case since libp
On Jun 23, 2025, at 6:32 AM, Denis Ovsienko wrote:
> Also there are forks of tcpdump and libpcap in the base system
> part of the major BSDs, some of these have diverged very substantially.
FreeBSD's is a fork that appear to get synced with each of our releases, so it
hasn't diverged much. It's
On Jul 4, 2025, at 8:55 AM, Bill Fenner wrote:
> We may know that we will be using this code on a kernel that
> requires BPF_SPECIAL_VLAN_HANDLING, and so I'd like to be able to set that
> flag on a "dead" handle. Obviously, the current mechanism is to test this
> dynamically when the handle is
On Jun 30, 2025, at 8:43 AM, Guy Harris wrote:
>> Perhaps we should implement that flag.
>
> ...and, if we do, and we split the lines in verbose mode for IPv6, the
> -g/--ip-oneline flag would apply both to IPv4 and IPv6.
If we implement the flag in the next 4.99.x release, t
On Jun 30, 2025, at 7:46 AM, Denis Ovsienko wrote:
> 1: https://github.com/the-tcpdump-group/tcpdump/issues/810
To quote a comment I added to that issue:
>> Personally, I'd prefer a single line of output for easy parsing.
>
>
> At one point, so did Apple, so they added a `-g` ("g" for "greppa
On Jul 8, 2025, at 7:36 AM, Denis Ovsienko wrote:
> The need to have a pcap_t at all times is very similar to using file
> descriptors or sockets: first you obtain a descriptor, then you
> initialise it in various ways as necessary, then you have a very small
> number of methods to read and to wr
On Jul 4, 2025, at 2:36 PM, Michael Richardson wrote:
> In general, it seems to me like we ought to specify some kind of target BPF
> processor option. As you say, pcap mostly just adapts itself to the current
> kernel, and the dead version has no options.
Currently, the possible backends are:
On Jul 7, 2025, at 6:42 AM, Denis Ovsienko wrote:
> One thing that can complicate this is that some always-true and
> always-false components are in fact specific to the link-layer type,
> for example, "ip" generates:
> * always-true for DLT_IPV4
> * always-false for DLT_IPV6
> * a load and a com
On Jul 7, 2025, at 3:29 AM, Denis Ovsienko wrote:
> Yes, and that version could be the same old pcap_compile() if the
> pcap_t contained the compilation style requests, as it already contains
> the link-layer type and the snapshot.
But that still requires pcap_open_dead(), which is somewhat of a
On Jul 8, 2025, at 7:58 AM, Denis Ovsienko wrote:
> On Mon, 7 Jul 2025 13:26:25 -0700
> Guy Harris wrote:
>
>> There could probably be a bunch of optimizations done to programs in
>> that IR.
>
> The parse tree, as a means of data handover between layers, wou
--- Begin Message ---
On Oct 21, 2019, at 5:59 PM, Mario Rugiero via tcpdump-workers
wrote:
> I think it's time to summarize, and to propose one last idea.
> I'm following the thread again to try and be as accurate as possible,
> but of course any objections are welcomed.
>
> - The oldest offic
--- Begin Message ---
On Oct 22, 2019, at 11:38 AM, Mario Rugiero wrote:
> El mar., 22 oct. 2019 a las 15:08, Guy Harris () escribió:
>
>> On Oct 21, 2019, at 5:59 PM, Mario Rugiero via tcpdump-workers
>> wrote:
>>> - TPACKET_V2 stays for immediate-mode support.
&g
--- Begin Message ---
On Oct 22, 2019, at 1:22 PM, Mario Rugiero wrote:
> El mar., 22 oct. 2019 a las 16:02, Guy Harris () escribió:
>> I.e., the goal for libpcap support on Linux should be something such as
>>
>>it should work on min({kernel for oldest
--- Begin Message ---
On Oct 22, 2019, at 2:24 PM, Mario Rugiero wrote:
> El mar., 22 oct. 2019 a las 18:01, Guy Harris () escribió:
>>
>> If RHEL 6 matters, oldest longterm from kernel.org only doesn't work,
>> because RHEL 6 runs 2.6.32, according to
>>
>
--- Begin Message ---
On Oct 23, 2019, at 12:26 AM, Anders Broman wrote:
> El mar., 22 oct. 2019 a las 15:08, Guy Harris () escribió:
>>
>>> Does it allow receiving copies of packets that are also handed either to
>>> the kernel networking stack or to other AF_XD
--- Begin Message ---
On Oct 23, 2019, at 1:43 AM, Anders Broman wrote:
> On Oct 23, 2019, at 12:26 AM, Anders Broman
> wrote:
>
>>> El mar., 22 oct. 2019 a las 15:08, Guy Harris ()
>>> escribió:
>>>>
>>>>> Does it allow receiving copie
--- Begin Message ---
(Looks Good To Me? Little Goggle-eyed Tiny Monkey?)
https://lgtm.com
has a number of open-source projects that it scans, including
https://lgtm.com/projects/g/the-tcpdump-group/libpcap/?mode=list
(mostly complaints about internal headers lacking header guar
--- Begin Message ---
On Feb 24, 2020, at 6:15 AM, Ray Bellis via tcpdump-workers
wrote:
> I've got a daemon that listens on a virtual IP address, that is itself
> attached to a cloned loopback interface on FreeBSD.
What do you mean by "loopback" here? The term "loopback interface" generally
--- Begin Message ---
On Feb 24, 2020, at 9:44 AM, Ray Bellis via tcpdump-workers
wrote:
> I never considered "any" ! But you appear to be suggesting it's not
> available in FreeBSD ?
It's not.
In Linux, packet capture is done with sockets created with a protocol family of
PF_PACKET. Those
--- Begin Message ---
On Mar 2, 2020, at 1:22 PM, Michael Richardson via tcpdump-workers
wrote:
> Back in 2016, we note in the CHANGES:
> Replace sprintf() with pcap_snprintf().
>
> but, we have no prototype for this, and apparently no definition, and we use
> snprintf() everywhere. I'm tryi
--- Begin Message ---
On Mar 2, 2020, at 1:51 PM, Guy Harris via tcpdump-workers
wrote:
> On Mar 2, 2020, at 1:22 PM, Michael Richardson via tcpdump-workers
> wrote:
>
>> Back in 2016, we note in the CHANGES:
>> Replace sprintf() with pcap_snprintf().
>>
>&
--- Begin Message ---
On Mar 2, 2020, at 2:08 PM, Guy Harris via tcpdump-workers
wrote:
> Or are you thinking of asprintf()? I didn't *think* that was available on
> Windows, so we would supply our own implementation, but AppVeyor appears to
> be finding it in recent bui
--- Begin Message ---
On Mar 20, 2020, at 2:39 PM, Nick Kelsey via tcpdump-workers
wrote:
> Pull request created (#919):
>
> https://github.com/the-tcpdump-group/libpcap/pull/919
I've added a proposed description as a comment to the pull request; please
check whether my assumptions are correc
--- Begin Message ---
On Mar 20, 2020, at 11:14 PM, Nick Kelsey wrote:
> I figure there will be interest in this protocol as we start to see ATSC 3.0
> test broadcasts. Our ATSC 3.0 hardware can output pcap data over HTTP in real
> time so ALP can be captured to file with a simple curl/wget com
--- Begin Message ---
There should probably be RFC-style specifications for 1) the pcap file format
and 2) the rpcapd protocol used for remote capturing.
Currently, on GitHub, there's a "pcapng" team:
https://github.com/pcapng
with one repository containing the pcapng specification, and
--- Begin Message ---
On Mar 21, 2020, at 2:31 PM, Mario Rugiero via tcpdump-workers
wrote:
> El sáb., 21 mar. 2020 18:15, Guy Harris via tcpdump-workers
> escribió:
>
>> 1) has the slight disadvantage that the name for the team suggests it's
>> for pcapng only; it
--- Begin Message ---
On Mar 21, 2020, at 2:14 PM, Guy Harris via tcpdump-workers
wrote:
> The options I see are:
4) add a new team for rpcap, as it's a protocol rather than a file format, and
thus only indirectly tied to pcap/pcapng, and putting the pcap format in the
pcapng team
--- Begin Message ---
On Mar 22, 2020, at 9:49 AM, Michael Tuexen
wrote:
> I would support this. However, last time I tried this, I was not successful.
> There were not very interested in defining a file format...
They've done so in the past:
https://tools.ietf.org/html/rfc1761 (and
h
--- Begin Message ---
On Mar 21, 2020, at 2:38 PM, Guy Harris via tcpdump-workers
wrote:
> On Mar 21, 2020, at 2:14 PM, Guy Harris via tcpdump-workers
> wrote:
>
>> The options I see are:
>
> 4) add a new team for rpcap, as it's a protocol rather than a fil
--- Begin Message ---
On Mar 22, 2020, at 10:29 AM, Guy Harris via tcpdump-workers
wrote:
> 5) ... and put pcap under the pcapng team as per the same reason as 4).
Done. It's pointed to by
https://github.com/pcapng/pcapng
and the XML source is at
https://github.co
--- Begin Message ---
On Mar 26, 2020, at 7:10 PM, Guy Harris via tcpdump-workers
wrote:
> (Note that its purpose is to document the *existing* format, rather than be a
> source of proposed changes.)
...proposed changes to the format.
I am, however, planning on proposing a mechani
--- Begin Message ---
Here's the proposal for "custom" link-layer types I threatened^Wpromised in my
earlier email.
A link-layer type value of 0x will be reserved as LINKTYPE_CUSTOM, with
libpcap offering a DLT_CUSTOM.
A custom link-layer type has a 32-bit IANA-registered Private Enterprise
--- Begin Message ---
> On Mar 30, 2020, at 10:24 AM, Francois-Xavier Le Bail
> wrote:
>
> Hi Guy,
>
> We have:
> $ git grep -n '"tcpdump"'
> netdissect.c:72:smiInit("tcpdump");
>
> netdissect.c is a part of libnetdissect.
>
> Should we use
> smiInit("libnetdissect");
> or something
--- Begin Message ---
On Mar 22, 2020, at 11:40 AM, Francois-Xavier Le Bail
wrote:
> On 22/03/2020 18:29, Guy Harris via tcpdump-workers wrote:
>
>> 5) Treat rpcap as "remote procedure call for libpcap" and put it under the
>> the-tcpdump-group team, and put pcap
--- Begin Message ---
On Apr 1, 2020, at 11:51 AM, Michael Richardson wrote:
> Guy Harris via tcpdump-workers wrote:
>>>
>>>> 5) Treat rpcap as "remote procedure call for libpcap" and put it under the
>>>> the-tcpdump-group team, and put pcap unde
--- Begin Message ---
On Apr 1, 2020, at 4:14 PM, Mario Rugiero via tcpdump-workers
wrote:
> I haven't yet been able to test it, which is why I've been delaying
> writing about this,
> but these two commits[0][1], which according to these threads[2][3]
> are the ones fixing
> the timeout issue,
--- Begin Message ---
(Opening this up to the full tcpdump-workers list, to get more user input.)
On Apr 30, 2020, at 11:40 AM, Francois-Xavier Le Bail
wrote:
> The tcpdump manual states:
>
> -x When parsing and printing, in addition to printing the headers
> of each
--- Begin Message ---
On May 5, 2020, at 3:15 AM, Gert Doering via tcpdump-workers
wrote:
> tcpdump's print-mpls.c already does "if I know what upper-layer protocol
> is in here, I call the appropriate printer". But there is no well-defined
> type field, so it fails for my packets, and and fall
--- Begin Message ---
On May 5, 2020, at 11:36 AM, Gert Doering via tcpdump-workers
wrote:
> So, given that the first 16 bits are "4 bit always 0, and 12 bits
> reserved-must-be-set-to-0", using these as heuristics for "if two 0-bytes
> are following the MPLS headers, it's a control word, so we
--- Begin Message ---
On May 7, 2020, at 12:04 AM, Francois-Xavier Le Bail via tcpdump-workers
wrote:
> On 07/05/2020 08:53, Guy Harris via tcpdump-workers wrote:
>
>> "Looks like a valid Ethernet address" is defined as "the first three octets
>> appear in Wir
--- Begin Message ---
On May 5, 2020, at 1:01 PM, Francois-Xavier Le Bail via tcpdump-workers
wrote:
> Wireshark MPLS heuristic is not perfect and has been criticized but is still
> there :-) hopefully
> correctly parsing your data as well.
*No* heuristic will be perfect here.
> For tcpdump m
--- Begin Message ---
On Mar 31, 2020, at 2:10 AM, Francois-Xavier Le Bail
wrote:
> On 31/03/2020 00:04, Petr Vorel wrote:
>> Hi Guy,
>>
BTW man pages (pcap.3pcap.in, pcap_datalink.3pcap.in, pcap_loop.3pcap and
pcap_next_ex.3pcap) mention only DLT_LINUX_SLL.
>>
>>> Fixed in commit ff
--- Begin Message ---
On Mar 31, 2020, at 2:10 AM, Francois-Xavier Le Bail
wrote:
> To avoid breaking program that cannot use SLL2,
Note, by the way, that one program that can't dissect LINKTYPE_LINUX_SLL2
packets is named "Wireshark".
No, nobody appears to have contributed a change to add su
--- Begin Message ---
On May 8, 2020, at 10:47 AM, Guy Harris via tcpdump-workers
wrote:
> No, nobody appears to have contributed a change to add support to
> epan/dissectors/packet-sll.c yet.
I just did; it was a significant enough change to a bit of infrastructure used
by other diss
--- Begin Message ---
On May 8, 2020, at 9:57 PM, Francois-Xavier Le Bail via tcpdump-workers
wrote:
> For a quick look, I don't need 'ifindex N', but I need 'In/Out,...'
>
> Thus I propose to print:
+1
--- End Message ---
___
tcpdump-workers mailing
--- Begin Message ---
BTW, having just implemented SLL2 support in Wireshark, the layout of the
header really doesn't work as well as I'd like with ARPHRD_NETLINK packets.
I'd prefer something like
struct header {
uint16_t hatype;/* link-layer address type */
uint
--- Begin Message ---
On May 24, 2020, at 4:37 AM, Francois-Xavier Le Bail via tcpdump-workers
wrote:
> 15 printers are missing in win32/prj/WinDump.dsp.
> Does anyone use it? Any reason to keep it ?
Note that the *supported* way to build tcpdump (and libpcap) on Windows is with
CMake (which c
--- Begin Message ---
On May 29, 2020, at 3:23 AM, Airbus CERT via tcpdump-workers
wrote:
> I would like to request you to get a DTL value for the PR
> https://github.com/the-tcpdump-group/libpcap/pull/934.
> This PR intend to add ETW capture for libpcap.
So is each packet an Event Tracing fo
--- Begin Message ---
On Jun 2, 2020, at 12:22 AM, Airbus CERT via tcpdump-workers
wrote:
> Yes exactly each packet is an event. The layout of the event is
> https://docs.microsoft.com/en-us/windows/win32/api/evntcons/ns-evntcons-event_header
> and
> https://docs.microsoft.com/en-us/windows/w
--- Begin Message ---
On Jun 8, 2020, at 12:24 PM, Francois-Xavier Le Bail
wrote:
> Thus all the files in win32/prj/ could be removed?
> (WinDump.dsp WinDump.dsw WinDump.sln WinDump.vcproj)
I have no problem removing them and requiring Windows users to ue CMake,
especially given that newer
--- Begin Message ---
On Jun 2, 2020, at 12:58 AM, Airbus CERT via tcpdump-workers
wrote:
> The layout is
> https://docs.microsoft.com/en-us/windows/win32/api/evntcons/ns-evntcons-event_header
So each packet's data starts with, in order:
a 2-octet event record size;
a 2-octet
2301 - 2400 of 2521 matches
Mail list logo
