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 pla
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.
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
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-kernel
> 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 somethi
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 an
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?
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
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 pas
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 pa
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, rat
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?)
_
12 matches
Mail list logo
