--- 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.
>>> - As a side-effect, RHEL6 r
--- 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
>> distribut
--- 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
>>
>>https://access.redhat.com/ar
--- 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 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 k
--- 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
--- 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, pcap_comp
--- 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:
> https://gistcdn.githack.com/sultanqa
--- 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 field
--- 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 list
--- 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:
> https://gistcdn.githack.com/sultanqasim/8b6561309f5934f084a0d938ae733b7a/raw/199fb1867642c927f768fe7d67dae2a639acb48e/LINKTYPE_BLUETOOTH_LE_LL_WITH_PHDR.html
--- 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 wan
--- 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 t
--- 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
> print.c:5
--- 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 ana
--- 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 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 wor
--- 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 wh
--- 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,
bu
--- 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
http://xml2rfc.tools.ietf.org/cgi-bin/
--- 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.
>>
>>
>> htt
--- 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 f
--- 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 ma
--- 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 neede
--- 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 17, 2020, at 4:19 PM, Guy Harris wrote:
> Or is there some site that will run kramdown-rfc2629 on a Markdown file and
> run xml2rfc on the result, along the lines of what xml2rfc.tools.ietf.org
> does? I haven't gotten
>
> https://xml2rfc.tools.ietf.org/expe
--- 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 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
kramdown-rf
--- 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 such
--- 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 privileg
--- 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 arguments,
--- 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 th
--- 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 both
--- 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 v
--- 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 macr
--- 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 handler
--- 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
> etc.
--- 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
> see
--- 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";
SUPP
--- 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 t
--- 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 s
--- 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 ---
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 5-10
--- 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
htt
--- 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 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 ac
--- 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
--- 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
> Specifica
--- 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 definitio
--- 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 traffi
--- 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
>sadd("src_
--- 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 pack
--- 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 yours
--- 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 i
--- 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 current
--- Begin Message ---
https://devblogs.microsoft.com/cppblog/address-sanitizer-for-msvc-now-generally-available/--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcp
--- Begin Message ---
On Feb 12, 2021, at 4:49 AM, developer--- via tcpdump-workers
wrote:
> Sorry for the delay in responding, I had to look thru the code to make sure
> all the information is accurate.
>
> I looked into the option to change in particular the msg_type 1 (decoded SIP
> messa
--- 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
> represent
--- 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 f
--- 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
>> op
1 - 100 of 162 matches
Mail list logo
