[tcpdump-workers] [RFC PATCH v2] Add new `pcap_set_buffer_size1` API.
From: Mario Rugiero
The current `pcap_set_buffer_size` sets a limit of 2GiB buffer size.
This changeset implements a backwards compatible mechanism to set
bigger buffers.
A new `pcap_set_buffer_size_ex` call is created, taking a `size_t`
instead of an `int`, allowing for buffers as big as the platform
allows.
The `buffer_size` field of `struct pcap_opt` was promoted to `size_t`.
Due to some contexts requiring smaller maximum buffers, a new field
named `max_buffer_size` of type `size_t` was added to the same structure
to account for that, as well as an analogous `min_buffer_size`.
This field is initialized by default to `INT_MAX` to preserve the
behaviour of the older API.
Then, each driver is expected, but not mandated, to fix them to more
suitable values for the platform.
In this RFC, Linux and DPDK are used as examples.
---
pcap-dpdk.c | 2 ++
pcap-int.h | 4 +++-
pcap-linux.c | 1 +
pcap.c | 15 +++
pcap/pcap.h | 5 +
5 files changed, 26 insertions(+), 1 deletion(-)
diff --git a/pcap-dpdk.c b/pcap-dpdk.c
index 6c2f21fc..81df91e3 100644
--- a/pcap-dpdk.c
+++ b/pcap-dpdk.c
@@ -964,6 +964,8 @@ pcap_t * pcap_dpdk_create(const char *device, char *ebuf,
int *is_ours)
if (p == NULL)
return NULL;
p->activate_op = pcap_dpdk_activate;
+ p->opt.max_buffer_size = SIZE_MAX;
+
return p;
}
diff --git a/pcap-int.h b/pcap-int.h
index b614efbe..5faa1efb 100644
--- a/pcap-int.h
+++ b/pcap-int.h
@@ -112,7 +112,9 @@ extern "C" {
struct pcap_opt {
char*device;
int timeout;/* timeout for buffering */
- u_int buffer_size;
+ size_t min_buffer_size;/* platform's min buffer size - backends
*should* override it */
+ size_t max_buffer_size;/* platform's max buffer size - backends
*should* override it */
+ size_t buffer_size;
int promisc;
int rfmon; /* monitor mode */
int immediate; /* immediate mode - deliver packets as soon as
they arrive */
diff --git a/pcap-linux.c b/pcap-linux.c
index 31c1a6a0..3b558237 100644
--- a/pcap-linux.c
+++ b/pcap-linux.c
@@ -517,6 +517,7 @@ pcap_create_interface(const char *device, char *ebuf)
handle->activate_op = pcap_activate_linux;
handle->can_set_rfmon_op = pcap_can_set_rfmon_linux;
+ handle->opt.max_buffer_size = SIZE_MAX;
#if defined(HAVE_LINUX_NET_TSTAMP_H) && defined(PACKET_TIMESTAMP)
/*
diff --git a/pcap.c b/pcap.c
index ebb992bf..f25fe4a9 100644
--- a/pcap.c
+++ b/pcap.c
@@ -2354,6 +2354,8 @@ pcap_create_common(char *ebuf, size_t size)
/* put in some defaults*/
p->snapshot = 0;/* max packet size unspecified */
p->opt.timeout = 0; /* no timeout specified */
+ p->opt.min_buffer_size = 0;
+ p->opt.max_buffer_size = INT_MAX; /* default to old API's max for
compatibility */
p->opt.buffer_size = 0; /* use the platform's default */
p->opt.promisc = 0;
p->opt.rfmon = 0;
@@ -2494,6 +2496,19 @@ pcap_set_buffer_size(pcap_t *p, int buffer_size)
return (0);
}
+int
+pcap_set_buffer_size_ex(pcap_t *p, size_t buffer_size)
+{
+ if (pcap_check_activated(p))
+ return (PCAP_ERROR_ACTIVATED);
+ if (buffer_size > p->opt.max_buffer_size)
+ return (PCAP_ERROR_BUFFER_TOO_BIG);
+ if (buffer_size < p->opt.min_buffer_size)
+ return (PCAP_ERROR_BUFFER_TOO_SMALL);
+ p->opt.buffer_size = buffer_size;
+ return (0);
+}
+
int
pcap_set_tstamp_precision(pcap_t *p, int tstamp_precision)
{
diff --git a/pcap/pcap.h b/pcap/pcap.h
index 21ea980a..303d58f2 100644
--- a/pcap/pcap.h
+++ b/pcap/pcap.h
@@ -305,6 +305,8 @@ typedef void (*pcap_handler)(u_char *, const struct
pcap_pkthdr *,
#define PCAP_ERROR_CANTSET_TSTAMP_TYPE -10 /* this device doesn't support
setting the time stamp type */
#define PCAP_ERROR_PROMISC_PERM_DENIED -11 /* you don't have permission to
capture in promiscuous mode */
#define PCAP_ERROR_TSTAMP_PRECISION_NOTSUP -12 /* the requested time stamp
precision is not supported */
+#define PCAP_ERROR_BUFFER_TOO_SMALL -13 /* attempted to set a buffer
below the minimum size */
+#define PCAP_ERROR_BUFFER_TOO_BIG -14 /* attempted to set a buffer
below the maximum size */
/*
* Warning codes for the pcap API.
@@ -340,6 +342,9 @@ PCAP_API intpcap_set_timeout(pcap_t *, int);
PCAP_API int pcap_set_tstamp_type(pcap_t *, int);
PCAP_API int pcap_set_immediate_mode(pcap_t *, int);
PCAP_API int pcap_set_buffer_size(pcap_t *, int);
+PCAP_API int pcap_set_buffer_size_ex(pcap_t *, size_t);
+PCAP_API size_tpcap_get_min_buffer_size(pcap_t *);
+PCAP_API size_tpcap_get_max_buffer_size(pcap_t *);
PCAP_API int pcap_set_tstamp_precision(pcap_t *, int);
PCAP_API int pcap_get_tstamp_precision(pcap_t *);
PCAP_API int pcap_activate(pcap_t *);
--
2.20.1
Re: [tcpdump-workers] Legacy Linux kernel support
El lun., 7 oct. 2019 a las 12:32, Michael Richardson () escribió: > > > Mario Rugiero wrote: > > The 'pcap-linux.c' implementation is plagued by #ifdefs and special > > cases aiming to support kernels as old as the 2.0.x family era. > > The oldest version supported by upstream is 3.16.74. > > > The most 'bleeding-edge' supported family has been there since the > > 2.6.y times, almost 10 years ago, so I think we can assume it's > > present on any current user's box. > > So what would be the oldest kernel that your revised code would support? > I'm reading 3.16? > Yes. Probably older, but as a side effect only, and I wouldn't like that support to be advertised. > > Anybody not upgrading the kernel for as long is very unlikely to want > > to update libpcap. > > Well, that's not really true. > There are many cases where people have to debug some silly appliance > that has been locked down to some 2.6 (or 2.4 due to binary blog drivers) > kernel. They often have to build libpcap/tcpdump elsewhere and copy the > binary over. > > Reasonably, though, they could probably build an old version of libpcap. > So, I would ask that the simplified code point to the last version of libpcap > (1.9) that will work in the error message. Your revision could be in 1.10. > That's reasonable. We could report it at runtime checking `uname` and at build time by checking `#ifdef`s and throwing a build time error. > > I think it would be useful to have the closest to a single build that > > we can get. > > I get having different builds for different user facing features > > (sniffing USB, for example), but not for something the user generally > > won't know, such as if the kernel where libpcap was built supported > > TPACKET V2 or V3. > > Yes, so the USB sniffer is not in pcap-linux.c, but pcap-usb-linux.c, and I > don't think you propose to change that. > Indeed, I'm not proposing touching that. > > In the same note, assuming an environment from this decade brings us > > some possibilities to write simpler and shorter code. > > For example, querying the present interfaces becomes way easier > > calling if_nameindex than the current crawl through sysfs. > > +1 > > Now that 1.9.1 is out, now is a great time to do this. > I will attempt to crawl through pull requests that update pcap-linux.c, and > see if there is any low-hanging fruit that we should merge before you > cleanup. I will make some tag for this. You may want to go ahead of me, as I > won't start before oct. 14, probably finish wednesday Oct. 16. > Great, I'll try to start this week. > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Legacy Linux kernel support
On Oct 3, 2019, at 6:12 PM, Mario Rugiero wrote:
> The 'pcap-linux.c' implementation is plagued by #ifdefs and special
> cases aiming to support kernels as old as the 2.0.x family era.
Heck, it may even support 1.x kernels with SOCK_PACKET support.
> The oldest version supported by upstream is 3.16.74.
> The most 'bleeding-edge' supported family has been there since the
> 2.6.y times, almost 10 years ago, so I think we can assume it's
> present on any current user's box.
A long time ago, I had the impression that 2.0.x kernels, and perhaps even 1.x
kernels, were popular for some small embedded systems; some of them might
perform networking functions, so that libpcap support might be useful, even if
they didn't run full-blown tcpdump, but just ran something that can write out a
pcap file to read on another machine.
If nobody's still doing that, we might as well get rid of, for example,
SOCK_PACKET support.
Currently, we do "immediate mode" capture with TPACKET_V2; I'm not sure whether
that, or non-memory-mapped capture, would be better for immediate mode.
> So far, there has been an objection regarding a bug on TPACKET V3 that
> is present in 3.16, but Guy pointed out libpcap already works around
> that, to which I add that this behaviour in libpcap can only be
> defined at build-time.
Which behavior can only be defined at build time?
The work-around itself is enabled or disabled based on the current running
kernel version; see set_poll_timeout().
The point there is that there isn't a version of the kernel that supports
TPACKET_V3 on which we can't use TPACKET_V3, given the workaround.
> I think it would be useful to have the closest to a single build that
> we can get.
> I get having different builds for different user facing features
> (sniffing USB, for example), but not for something the user generally
> won't know, such as if the kernel where libpcap was built supported
> TPACKET V2 or V3.
We don't #ifdef around whether the kernel on which we'll be *running* has
TPACKET_V3.
We #ifdef around whether the *headers with which we're building* have the
#defines, structures, etc. needed to compile the code that supports TPACKET_V3.
If we were to drop TPACKET_V1 and TPACKET_V2 support, that'd mean we'd be
dropping 2.x kernels and older 3.x kernels as targets, and would require that
the headers with which libpcap is being built be new enough to support
TPACKET_V3.
> Examples of what I'd like to see removed are:
> TPACKET V1 and V2 handling. This includes some special casing for VLAN tags.
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
buffer into userland), but:
immediate mode is generally used for people (ab)using libpcap to
implement protocols at the link layer, where you aren't necessarily dealing
with the packet firehose you can get when doing sniffing;
memory-mapped mode means declaring a maximum-sized buffer for packets,
so it may consume more memory for the buffering;
so non-memory-mapped capturing might be a better fit.
("(Ab)using" in the sense that perhaps there should be a *separate* library for
use by code implementing protocols that run directly atop the link layer; on
some platforms - not just Linux - that code might use a completely different
mechanism from the mechanism used by libpcap.)
> SOCK_PACKET. All of it.
Unless there are still important small embedded devices or whatever 1) for
which there's a good reason to run a 2.0.x (or 1.x) kernel, 2) for which
there's a need to run libpcap-based code on the device, and 3) on which they'd
really want to build the Latest Newest Shiniest version of libpcap, yes, drop
SOCK_PACKET support.
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Legacy Linux kernel support
On Oct 7, 2019, at 10:27 AM, Guy Harris wrote: > If we were to drop TPACKET_V1 and TPACKET_V2 support, that'd mean we'd be > dropping 2.x kernels and older 3.x kernels as targets It looks as if TPACKET_V3 might have first appeared in the 3.2 kernel: https://www.fclose.com/linux-kernels/358414/af-packet-tpacket_v3-flexible-buffer-implementation-linux-3-2/ ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Legacy Linux kernel support
> A long time ago, I had the impression that 2.0.x kernels, and perhaps even
> 1.x kernels, were popular for some small embedded systems; some of them might
> perform networking functions, so that libpcap support might be useful, even
> if they didn't run full-blown tcpdump, but just ran something that can write
> out a pcap file to read on another machine.
>
> If nobody's still doing that, we might as well get rid of, for example,
> SOCK_PACKET support.
>
Even if they are, I'm not sure why they would want to update libpcap
in that case.
> > So far, there has been an objection regarding a bug on TPACKET V3 that
> > is present in 3.16, but Guy pointed out libpcap already works around
> > that, to which I add that this behaviour in libpcap can only be
> > defined at build-time.
>
> Which behavior can only be defined at build time?
>
> The work-around itself is enabled or disabled based on the current running
> kernel version; see set_poll_timeout().
>
> The point there is that there isn't a version of the kernel that supports
> TPACKET_V3 on which we can't use TPACKET_V3, given the workaround.
>
Yes, I was typing faster than I was thinking. I meant at run-time.
> > I think it would be useful to have the closest to a single build that
> > we can get.
> > I get having different builds for different user facing features
> > (sniffing USB, for example), but not for something the user generally
> > won't know, such as if the kernel where libpcap was built supported
> > TPACKET V2 or V3.
>
> We don't #ifdef around whether the kernel on which we'll be *running* has
> TPACKET_V3.
>
> We #ifdef around whether the *headers with which we're building* have the
> #defines, structures, etc. needed to compile the code that supports
> TPACKET_V3.
>
Yes. This still makes for different builds, and this still means what
the kernel headers define may not match what the user has.
If we support only newer kernels at run-time, it makes sense that we
support only newer kernels at build-time.
> If we were to drop TPACKET_V1 and TPACKET_V2 support, that'd mean we'd be
> dropping 2.x kernels and older 3.x kernels as targets, and would require that
> the headers with which libpcap is being built be new enough to support
> TPACKET_V3.
>
Yes. That's what I'm proposing.
> 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
> buffer into userland), but:
>
> immediate mode is generally used for people (ab)using libpcap to
> implement protocols at the link layer, where you aren't necessarily dealing
> with the packet firehose you can get when doing sniffing;
>
Hmmm, I use memory-mapping precisely to deal with that fire hose
without dropping too much.
> memory-mapped mode means declaring a maximum-sized buffer for
> packets, so it may consume more memory for the buffering;
>
I could argue that declaring this maximum-sized buffer may give you
more control over the memory consumption instead.
> so non-memory-mapped capturing might be a better fit.
>
Isn't pcap currently using memory-mapping whenever it can?
> ("(Ab)using" in the sense that perhaps there should be a *separate* library
> for use by code implementing protocols that run directly atop the link layer;
> on some platforms - not just Linux - that code might use a completely
> different mechanism from the mechanism used by libpcap.)
>
That's a weird use-case indeed. I'm not sure libpcap is that bad of an
option for this.
> > SOCK_PACKET. All of it.
>
> Unless there are still important small embedded devices or whatever 1) for
> which there's a good reason to run a 2.0.x (or 1.x) kernel, 2) for which
> there's a need to run libpcap-based code on the device, and 3) on which
> they'd really want to build the Latest Newest Shiniest version of libpcap,
> yes, drop SOCK_PACKET support.
The thing is, we can never know that there aren't. We can only know
there are, if someone asks for support for them.
It's a leap of faith.
I think I'd rather just fix security bugs (easy to say, not being the
maintainer, heh) and backport them to some kind of LTS release than do
the main development with it polluting the code-base.
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] Legacy non-Linux support
While we're discussing dropping support for older OSes: Do we still need to worry about: SunOS prior to 4.x NIT? SunOS 4.x STREAMS NIT? IRIX? DEC OSF/1^W^WDigital UNIX^W^WTru64 UNIX? And do we need to continue supporting being built with WinPcap's packet.dll and header files, or can we just support Npcap? ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Legacy non-Linux support
Hi, On Mon, Oct 07, 2019 at 11:29:24AM -0700, Guy Harris wrote: > While we're discussing dropping support for older OSes: > > Do we still need to worry about: > > SunOS prior to 4.x NIT? > > SunOS 4.x STREAMS NIT? > > IRIX? > > DEC OSF/1^W^WDigital UNIX^W^WTru64 UNIX? My take on this on other projects has been "no, because if they really need it, they can always compile an older version of libFOO, and use that". (This is also relevant for questions like "can we start using C99 features, even if SunOS 4 does not have C99 compiler") The risk in cutting off support for legacy things (Linux 1.x, SunOS 4, etc.) is that you might need to do a "libpcap.old.1" release in case a security critical bug is found. But I certainly can't tell you what to do, just bring in a few cents of thinking, as someone who maintains "portable" unix stuff, and also loves running old machines :-) (so, don't drop support for SunOS 4 in tcpdump) gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Legacy Linux kernel support
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 buffer into userland), but:
>>
>>immediate mode is generally used for people (ab)using libpcap to
>> implement protocols at the link layer, where you aren't necessarily dealing
>> with the packet firehose you can get when doing sniffing;
>
> Hmmm, I use memory-mapping precisely to deal with that fire hose
> without dropping too much.
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 traffic,
you still get a packet firehose?
>>memory-mapped mode means declaring a maximum-sized buffer for
>> packets, so it may consume more memory for the buffering;
>
> I could argue that declaring this maximum-sized buffer may give you
> more control over the memory consumption instead.
How so? There's no way to specify, with TPACKET_V3, "deliver a block as soon
as there is a packet in it" (unless I've missed something), which is what
immediate mode means, so, for memory-mapped capturing in immediate mode, we
have to fall back on TPACKET_V1 or TPACKET_V2.
With TPACKET_V1 or V2, the frame size is fixed, and must be >= the largest
amount of data you will get in a frame. If the frame is shorter than that,
there's wasted space.
With TPACKET_V3, the frame size isn't fixed, so if you have a snapshot length
of 1514 bytes but the frame is only 60 bytes, you don't get 1454 bytes of
wasted space.
>> so non-memory-mapped capturing might be a better fit.
>
> Isn't pcap currently using memory-mapping whenever it can?
Yes, but *should* it do so for immediate mode?
In immediate mode, with TPACKET_V1 or V2, you have wasted space, as per the
above. With non-memory-mapped capture, you just get skbuffs attached to the
socket; I don't know if Linux has the equivalent of what the "loaned mbufs"
some BSD-style stacks have, where the skbuff would directly point to a driver
ring buffer slot, in which case there would probably still be wasted space (and
in which case, if you don't consume the packet quickly, the adapter could run
out of buffers), or if they're copied, in which case the target skbuff might
not be full sized and there'd be less wasted memory.
>> ("(Ab)using" in the sense that perhaps there should be a *separate* library
>> for use by code implementing protocols that run directly atop the link
>> layer; on some platforms - not just Linux - that code might use a completely
>> different mechanism from the mechanism used by libpcap.)
>
> That's a weird use-case indeed.
There are some protocols that work that way, and I think I remember at least
one person complaining about an impedance mismatch between what libpcap offered
and what they needed.
> I'm not sure libpcap is that bad of an option for this.
One of the aforementioned impedance matches is that the protocol implementation
might want only one particular Ethernet type or one particular OUI/PID
combination for SNAP frames - that could be done with a packet filter, but the
OS mechanism might have a way to do it directly (binding to a particular
protocol with Linux PF_PACKET sockets, binding to a particular SAP rather than
setting SAP-promiscuous mode with DLPI, something else with the *non-BPF*
mechanism that may be a better fit for this in macOS).
I'd have to find my notes from when I was looking at what an alternative
library might do to see what some of the other ones are.
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Legacy Linux kernel support
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 traffic, > you still get a packet firehose? > No, I get a packet fire hose because I passively sniff. The protocol idea is new to me. > How so? There's no way to specify, with TPACKET_V3, "deliver a block as soon > as there is a packet in it" (unless I've missed something), which is what > immediate mode means, so, for memory-mapped capturing in immediate mode, we > have to fall back on TPACKET_V1 or TPACKET_V2. > > With TPACKET_V1 or V2, the frame size is fixed, and must be >= the largest > amount of data you will get in a frame. If the frame is shorter than that, > there's wasted space. > > With TPACKET_V3, the frame size isn't fixed, so if you have a snapshot length > of 1514 bytes but the frame is only 60 bytes, you don't get 1454 bytes of > wasted space. > > >> so non-memory-mapped capturing might be a better fit. > > > > Isn't pcap currently using memory-mapping whenever it can? > > Yes, but *should* it do so for immediate mode? > Good time to discuss (and fix it?), then :) > In immediate mode, with TPACKET_V1 or V2, you have wasted space, as per the > above. With non-memory-mapped capture, you just get skbuffs attached to the > socket; I don't know if Linux has the equivalent of what the "loaned mbufs" > some BSD-style stacks have, where the skbuff would directly point to a driver > ring buffer slot, in which case there would probably still be wasted space > (and in which case, if you don't consume the packet quickly, the adapter > could run out of buffers), or if they're copied, in which case the target > skbuff might not be full sized and there'd be less wasted memory. > Hmmm, that makes sense. I thought the concern was about total memory use. Give me a day or two to check the sources on how the skbuff gets exposed. > One of the aforementioned impedance matches is that the protocol > implementation might want only one particular Ethernet type or one particular > OUI/PID combination for SNAP frames - that could be done with a packet > filter, but the OS mechanism might have a way to do it directly (binding to a > particular protocol with Linux PF_PACKET sockets, binding to a particular SAP > rather than setting SAP-promiscuous mode with DLPI, something else with the > *non-BPF* mechanism that may be a better fit for this in macOS). > > I'd have to find my notes from when I was looking at what an alternative > library might do to see what some of the other ones are. Interesting. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Legacy Linux kernel support
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 >> traffic, you still get a packet firehose? >> > No, I get a packet fire hose because I passively sniff. And presumably you're not doing that in immediate mode. (tcpdump *currently* uses immediate mode if it's in sniff-and-print mode, but maybe it should select a shorter timeout instead - and perhaps, these days, a 1-second timeout is too much even if you're capturing to a file.) > The protocol idea is new to me. And that's where I'm saying we might want to use non-memory-mapped capturing. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Legacy Linux kernel support
El lun., 7 oct. 2019 17:05, Guy Harris escribió: > 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 traffic, you still get a packet firehose? > >> > > No, I get a packet fire hose because I passively sniff. > > And presumably you're not doing that in immediate mode. (tcpdump > *currently* uses immediate mode if it's in sniff-and-print mode, but maybe > it should select a shorter timeout instead - and perhaps, these days, a > 1-second timeout is too much even if you're capturing to a file.) > I don't think so, but I should probably check. > > > The protocol idea is new to me. > > And that's where I'm saying we might want to use non-memory-mapped > capturing. I see. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Legacy non-Linux support
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 10.7 and later?) ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
