--- 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
--- 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 supported enterprise
>>
--- 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 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 copies of packets that are also handed either to
> the
--- 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.
>>> - As a side-effect, RHEL6
--- 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
--- 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_XDP sockets for regular input
--- 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.
--- 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 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 builds.
--- 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
--- 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 Mar 26, 2020, at 7:10 PM, Guy Harris via tcpdump-workers
wrote:
> (Note that its purpose is to document the *existing* format, rather than be a
> source of proposed changes.)
...proposed changes to the format.
I am, however, planning on proposing a mec
--- 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
--- Begin Message ---
On Mar 22, 2020, at 10:29 AM, Guy Harris via tcpdump-workers
wrote:
> 5) ... and put pcap under the pcapng team as per the same reason as 4).
Done. It's pointed to by
https://github.com/pcapng/pcapng
and the XML source is at
https://github.com/pca
--- 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
--- 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 ---
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 */
--- 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
--- 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
--- 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 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
--- 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
--- 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
--- 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
--- 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,
--- Begin Message ---
On Mar 21, 2020, at 2:31 PM, Mario Rugiero via tcpdump-workers
wrote:
> El sáb., 21 mar. 2020 18:15, Guy Harris via tcpdump-workers
> escribió:
>
>> 1) has the slight disadvantage that the name for the team suggests it's
>> for pcapng only; it a
--- Begin Message ---
On Mar 21, 2020, at 2:14 PM, Guy Harris via tcpdump-workers
wrote:
> The options I see are:
4) add a new team for rpcap, as it's a protocol rather than a file format, and
thus only indirectly tied to pcap/pcapng, and putting the pcap format in the
pcapng team beca
--- 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
--- Begin Message ---
On Mar 21, 2020, at 2:38 PM, Guy Harris via tcpdump-workers
wrote:
> On Mar 21, 2020, at 2:14 PM, Guy Harris via tcpdump-workers
> wrote:
>
>> The options I see are:
>
> 4) add a new team for rpcap, as it's a protocol rather than a file for
--- 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
--- Begin Message ---
This is not a security issue; questions about tcpdump should be sent to
tcpdump-workers@lists.tcpdump.org, which is where I'm sending this question.
On Sep 14, 2020, at 8:22 PM, Accepted <532876...@qq.com> wrote:
> hi, in this picture, I try to use tcpdump to get package
--- Begin Message ---
On Oct 17, 2020, at 6:01 PM, Michael Richardson wrote:
> Guy Harris via tcpdump-workers wrote:
>
>> So is there anything we do to arrange that the "Current committed
>> version as ..." links on the GitHub repository home page work again?
&g
--- Begin Message ---
On Oct 17, 2020, at 4:19 PM, Guy Harris wrote:
> Or is there some site that will run kramdown-rfc2629 on a Markdown file and
> run xml2rfc on the result, along the lines of what xml2rfc.tools.ietf.org
> does? I haven't gotten
>
>
--- Begin Message ---
On Sep 28, 2020, at 4:28 PM, Michael Richardson wrote:
> Guy Harris wrote:
>> For 2), I note that
>
>>
>> https://github.com/pcapng/pcapng/blob/master/draft-tuexen-opsawg-pcapng.md
>
>> has a bunch of stuff that GitHub isn't treating as markup, such as the
>> stuff
--- Begin Message ---
On Oct 18, 2020, at 1:32 AM, Michael Tuexen wrote:
> Just a note. I'm using the .xml format and put a link in the README.md, which
> shows the .txt or .html file based on the current .xml.
Yes, that's what we were doing for the pcapng draft before switching to
--- Begin Message ---
On Oct 7, 2020, at 1:30 PM, Fernando Gont via tcpdump-workers
wrote:
> WHile using pcap_inject() in Linux, it is failing with "pcap_inject(): send:
> Resource temporarily unavailable". In principle, one would expect that for
> temporary problems (such as this one), one
--- Begin Message ---
On Oct 7, 2020, at 3:16 PM, Denis Ovsienko via tcpdump-workers
wrote:
> Do you mean to introduce a function like pcap_error(), which the
> developers would be able to interrogate if they need in use cases like
> this? Then existing functions could be slowly updated as
--- Begin Message ---
On Aug 21, 2020, at 2:48 PM, Denis Ovsienko via tcpdump-workers
wrote:
> The man page says:
>
> (In older versions of libpcap, the behavior when cnt was 0
> was undefined; different platforms and devices behaved
> differently, so code that must
--- Begin Message ---
On Sep 29, 2020, at 7:14 PM, Qin Wu wrote:
> Can you clarify what functionalities is missed for more modern applications?
> Since it is enhancement to libpcap, do you expect all the future packet
> capture tools support the format defined in this draft?
pcapng is a file
--- Begin Message ---
On Sep 28, 2020, at 12:06 PM, Michael Tuexen wrote:
> On 28. Sep 2020, at 20:26, Michael Richardson wrote:
>
>> internet-dra...@ietf.org wrote:
>>> Diff:
>>> https://www.ietf.org/rfcdiff?url2=draft-tuexen-opsawg-pcapng-02
>>
>> Hi, I have converted the xml to markdown.
>
--- Begin Message ---
On Sep 28, 2020, at 1:42 PM, Michael Tuexen wrote:
> Shouldn't we write up (I can work on an initial version) of
> a specification for .pcap.
https://github.com/pcapng/pcapng/blob/master/draft-gharris-opsawg-pcap.xml
--- Begin Message ---
On Sep 28, 2020, at 12:06 PM, Michael Tuexen wrote:
> Do we want to finally publish that? Up to now, I think the point was to
> find a home where it is substantially discussed and improved...
For example, unlike pcap, which is not easily changeable (you *can* change it,
--- Begin Message ---
On Sep 28, 2020, at 2:00 PM, Michael Tuexen wrote:
> On 28. Sep 2020, at 22:48, Guy Harris wrote:
>
>> On Sep 28, 2020, at 1:42 PM, Michael Tuexen wrote:
>>
>>> Shouldn't we write up (I can work on an initial version) of
>>> a specification for .pcap.
>>
>>
>>
--- 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
--- 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
--- 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
>
--- Begin Message ---
On Oct 21, 2020, at 1:56 PM, Aki Van Ness via tcpdump-workers
wrote:
> I'm working on a project that plans to store PCI and PCI-Express
> packets in the pcapng format as that's the most appropriate storage
> format and I really rather not roll something custom.
>
> As
--- Begin Message ---
On Aug 3, 2020, at 12:33 PM, Denis Ovsienko via tcpdump-workers
wrote:
>
> Whilst updating the description of files in tcpslice (the little
> relative of tcpdump) repository, it came to my attention that it does
> not have the customary LICENSE file. I have looked through
--- Begin Message ---
(Your first attempt seems to have worked - finally. Perhaps Michael cleared
the backlog?)
On Aug 10, 2020, at 4:24 AM, Denis Ovsienko via tcpdump-workers
wrote:
> It turns out, pcap_compile_nopcap() has been a part of the libpcap API
> since version 0.5 (June 2000), but
--- Begin Message ---
On Aug 11, 2020, at 4:55 AM, Bill Fenner via tcpdump-workers
wrote:
> Is there a plan for a public face for libnetdissect?
At some point we should probably do that.
(Back in the late '90's, I discovered a program called tcpview, which was a
Motif(!)-based GUI network
--- Begin Message ---
On Aug 4, 2020, at 1:28 PM, Francois-Xavier Le Bail
wrote:
> lane_if_print() in print-lane.c
> (Added by 77b2a4405561467f66a3dfb0f8ce2b0eaa5ebaf9 in Sun Nov 21 1999 "print
> of ATM LanEmulation")
> is called for DLT_LANE8023:
>
> print.c-56-#ifdef DLT_LANE8023
>
--- Begin Message ---
On Aug 12, 2020, at 1:31 PM, Guy Harris via tcpdump-workers
wrote:
> We should probably have an include/libnetdissect directory in which we
> install netdissect.h and the headers it requires.
Or include/netdissect.
> However, API-declaring headers should *NEVER
--- Begin Message ---
On Jul 10, 2020, at 2:57 PM, Sultan Khan wrote:
> Link to the updated version of the spec with the latest changes:
>
--- Begin Message ---
On Jul 13, 2020, at 9:02 AM, Sultan Khan wrote:
> Thanks Chris. I’ll make a pull request to tcpdump-htdocs later today, and
> I’ll include a link to the previous version of the spec as an archive.org
> link to the old one on whiterocker.com.
The new version is a superset
--- Begin Message ---
On Jul 13, 2020, at 8:09 AM, Sultan Khan wrote:
> Hmm. Chris Kilgour (whiterocker) originally created the spec, and the version
> on tcpdump.org was just a backup copy. Now, Chris has said that he is no
> longer active in the Bluetooth LE sniffing space, and he doesn’t
--- Begin Message ---
A couple more editorial comments:
In the description of the bits in the Flags field, I'd describe the 0x3000 bits
as "PDU type dependent", and, after they're listed indicate that:
For PDU types other than type 1 (auxiliary advertising), the PDU type
dependent
--- Begin Message ---
For an advertising physical channel PDU, it appears that the PDU type is in the
least-significant 4 bits of the PDU header.
Is that not present in an auxiliary advertising packet?--- End Message ---
___
tcpdump-workers mailing
--- Begin Message ---
On Jul 9, 2020, at 1:46 PM, Sultan Khan wrote:
> Through discussions with Joakim Anderson (of Nordic) and Mike Ryan (Ubertooth
> developer), and going through several iterations of proposed protocol
> updates, I/we came up with this:
>
--- 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
--- Begin Message ---
François checked in a change to tcpdump so that, if it's handed a capture file
with a link-layer header type for which it has no dissector, it just dumps the
packet data in hex, rather than failing with an indication that the header type
isn't supported.
However,
--- Begin Message ---
On Sep 9, 2020, at 9:07 AM, Denis Ovsienko via tcpdump-workers
wrote:
> The "Found pcap-config" message means that FindPCAP.cmake has not found
> libpcap by means of pkg-config, and the lack of the message means the
> pkg-config method worked. A few weeks ago Ubuntu 18.04
--- Begin Message ---
On Jan 7, 2021, at 9:35 AM, Bill Fenner via tcpdump-workers
wrote:
> These jobs are still failing, but now for a different reason.
Part of the problem is that pkg-config wasn't finding the locally-installed
libpcap under /tmp, because PKG_CONFIG_PATH wasn't set to point
--- Begin Message ---
On Jan 7, 2021, at 3:21 PM, Guy Harris via tcpdump-workers
wrote:
> So we should either 1) require CMake 3.1 or later or 2) forcibly set
> PKG_CONFIG_USE_CMAKE_PREFIX_PATH to YES. For now, my inclination is to do
> the latter.
That w
--- Begin Message ---
(Resent, from the correct address this time.)
On Dec 21, 2020, at 5:51 PM, Michael Richardson wrote:
> The short of it is:
>
> 1) reserve bits 16:28 of linktype as zero.
In pcap files, presumably; you have only bits 0:15 in pcapng IDBs.
Note that the registry is for
--- Begin Message ---
On Dec 22, 2020, at 1:01 AM, Guy Harris wrote:
> They were originally intended for use with some stuff NetBSD was doing (I'd
> have to look into the history of the NetBSD code), but I think NetBSD stopped
> doing that.
The commit message for the change that added the
--- Begin Message ---
On Dec 21, 2020, at 4:31 PM, Michael Richardson wrote:
> Hi, I have reworked the document that Guy put into XML describing the *PCAP*
> (not NG) format. I found the text for LinkType to be confusing, and
> frankly, I think wrong.
>
> * LinkType (32 bits): an unsigned
--- Begin Message ---
On Dec 22, 2020, at 8:36 AM, Michael Richardson wrote:
> Guy Harris wrote:
>
>> And, as per my idea of using 65535 to mean "custom linktype", similar
>> to pcapng custom blocks and options, with either:
>
> I'm happy with this proposal, but isn't it pcapng specific?
No
--- Begin Message ---
On Dec 22, 2020, at 2:05 PM, Linus Lüssing via tcpdump-workers
wrote:
> I was experimenting a bit with migrating from the use of
> pcap_offline_filter() to pcap_setfilter().
>
> I was a bit surprised that installing for instance 500 pcap
> handlers
What is a "pcap
--- Begin Message ---
On Dec 22, 2020, at 3:31 PM, Linus Lüssing wrote:
> Basically we want to do live measurements of the overhead of the mesh
> routing protocol and measure and dissect the layer 2 broadcast traffic.
> To measure how much ARP, DHCP, ICMPv6 NS/NA/RS/RA, MDNS, LLDP overhead
>
--- Begin Message ---
What happens if you put
printf("Version: %s\n", pcap_lib_version());
before the pcap_lookupdev() call?
It won't fix the pcap_lookupdev() call not to return NULL, but it'll indicate
what version of libpcap your program is using, which might help determine what
the
--- Begin Message ---
On Nov 4, 2020, at 9:18 PM, Vaughan Wickham wrote:
> Version: libpcap version 1.5.3
That's an older version (CentOS, proudly trailing-edge!), and only returns
interfaces that the program can open.
Capturing on Linux generally requires, at minimum, the CAP_NET_RAW
--- Begin Message ---
On Nov 4, 2020, at 10:26 PM, Vaughan Wickham wrote:
> In regards to your latest comments regarding
>
> sudo setcap cap_net_raw,cap_net_admin+eip {your program}
>
> Are you saying that I need to compile my program and then start the compiled
> version with these
--- Begin Message ---
On Nov 5, 2020, at 1:04 AM, Vaughan Wickham wrote:
> Appreciate all the info that you have provided.
>
> Although it probably doesn't look like it from my questions; I did actually
> read some tutorials prior to posting my initial question; and none made
> reference to
--- Begin Message ---
On Jan 3, 2021, at 12:15 PM, Denis Ovsienko via tcpdump-workers
wrote:
> tcpdump source tree has a short file named "Readme.Win32", which was
> mostly updated on 8 Aug 2019, and a longer file named
> "doc/README.Win32.md", which was mostly updated on 5 Feb 2020. These
>
--- Begin Message ---
$ curl -s
https://opensource.apple.com/source/tcpdump/tcpdump-100/tcpdump.xcodeproj/project.pbxproj.auto.html
| egrep SUPPORTED_PLATFORMS
SUPPORTED_PLATFORMS = macosx iphoneos
appletvos watchos bridgeos;
--- Begin Message ---
On Jan 7, 2021, at 5:41 PM, Denis Ovsienko via tcpdump-workers
wrote:
> 5 years of backward compatibility might be OK'ish, although from time
> to time I run into such "long-term support" systems that in practice
> mean someone keeps paying good money for "support" for
--- Begin Message ---
On Jan 21, 2021, at 8:41 AM, Bill Fenner via tcpdump-workers
wrote:
> It would be perfectly reasonable (and fairly straightforward) to update
> libpcap to be able to filter on the Ethernet address in DLT_LINUX_SLL or
> DLT_LINUX_SLL2 mode.
Link-layer address, to be more
--- Begin Message ---
On Jan 22, 2021, at 2:54 PM, Denis Ovsienko via tcpdump-workers
wrote:
> I have tested it again with the current master branches of libpcap and
> tcpdump. Both builds (with and without libpcap0.8-dev) now complete
> without errors.
>
> However, in both cases the installed
--- Begin Message ---
On Jan 22, 2021, at 7:11 PM, Guy Harris via tcpdump-workers
wrote:
> I'll try experimenting with one of my Ubuntu VMs.
Welcome to Shared Library Search Hell.
Most UN*Xes have a notion of RPATH (with, of course, different compiler
command-line flags to set it).
p
--- Begin Message ---
On Dec 16, 2020, at 8:09 PM, Yao, Jiewen via tcpdump-workers
wrote:
> I write this email to request to below 2 link types.
>
>
> 1. MCTP
...
> MCTP packet is defined in DMTF PMCI working group Management Component
> Transport Protocol (MCTP) Base
>
--- Begin Message ---
Travis CI is announcing on the travis-ci.org site that "... travis-ci.org will
be shutting down in several weeks, with all accounts migrating to
travis-ci.com. Please stay tuned here for more information."
They don't provide any information there. However, at
--- Begin Message ---
On Feb 3, 2021, at 6:54 AM, developer--- via tcpdump-workers
wrote:
> We would like to request a dedicated LINKTYPE_* / DLT_* code.
> Auerswald is a major German telecommunications equipment manufacturer.
> We have implemented the option to capture (combined) network
--- Begin Message ---
On Feb 4, 2021, at 3:41 AM, developer--- via tcpdump-workers
wrote:
> We currently use this code in our lua dissector to display (decoded) SIP
> messages.
>
> -- offsets will change with the new LINKTYPE
>if (buf(148,2):uint() == MSG_TYPE_SIP) then
>
--- Begin Message ---
On Dec 16, 2020, at 8:09 PM, Yao, Jiewen via tcpdump-workers
wrote:
> We did a prototype for the SpdmDump tool
> (https://github.com/jyao1/openspdm/blob/master/Doc/SpdmDump.md). We can
> generate a PCAP file and parse it offline.
> In our prototype, we use below
--- Begin Message ---
https://twitter.com/MeghanEMorris/status/1382109954224521216/photo/1
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
--- Begin Message ---
On Mar 22, 2021, at 7:33 AM, Jan Adam wrote:
>> Are they aligned on natural boundaries?
>
> No, it is not aligned but packet. We use #pragma pack(1) for the footer
> structure.
You should probably add that to the page with the structure definition.
>> What do the four
--- Begin Message ---
On Mar 22, 2021, at 5:35 PM, Denis Ovsienko via tcpdump-workers
wrote:
> On Mon, 22 Mar 2021 19:00:31 +0100
> Harald Welte wrote:
...
>> btw: I'm not sure if qemu full system emulation of e.g. ppc on a
>> x86_64 hardware would be an option, though. I think
>>
--- Begin Message ---
On Mar 24, 2021, at 12:32 AM, Jan Adam wrote:
>> So, with incl_len equal to {PayloadSize,VarSize} + 54, orig_len would be
>> equal to {original PayloadSize} + 54, so the original payload size would be
>> orig_len - 54.
>>
>> That would allow the original size and the
--- Begin Message ---
On Mar 12, 2021, at 4:35 AM, Jan Adam wrote:
>> So is "the variable" the same thing as "the payload"?
>
> That is correct. To be more specific the payload is the value/content of the
> variable.
Can the variable be anything *other* than a packet of some sort? The
--- Begin Message ---
On Mar 15, 2021, at 9:04 AM, Jan Adam wrote:
>> Can the variable be anything *other* than a packet of some sort?
>
> There are only the mentioned 5 representations planned for pcap files since
> this is what our capture device may capture into a pcap file. The
>
--- Begin Message ---
On Mar 8, 2021, at 12:07 AM, Jan Adam via tcpdump-workers
wrote:
> We have created a public document on our website You can point to for the
> description.
>
> Here is the link: https://kb.hilscher.com/x/brDJBw
>
> It contains a more detailed description of the fields
--- Begin Message ---
On Mar 3, 2021, at 8:58 AM, Jan Adam via tcpdump-workers
wrote:
> for our new analysis product netANALYZER NG I would like to request a new
> link-layer type value.
>
> NETANALYZER_NG
>
> The new Link-Layer-Type format is described as following:
>
> Next-generation
--- Begin Message ---
On Mar 3, 2021, at 2:30 PM, Denis Ovsienko via tcpdump-workers
wrote:
> A partial replacement for that service is ci.tcpdump.org, which is a
> buildbot instance doing Linux AArch64 builds for the github.com
> repositories.
So where is that hosted? Are you hosting it
1 - 100 of 160 matches
Mail list logo
