El mié., 2 oct. 2019 a las 18:46, Guy Harris (<ghar...@sonic.net>) escribió:
>
> On Oct 2, 2019, at 2:16 PM, Mario Rugiero <mrugi...@gmail.com> wrote:
>
> > A new `pcap_set_buffer_size1` call is created, taking a `size_t`
> > instead of an `int`, allowing for buffers as big as the platform
> > allows.
>
> Perhaps pcap_set_buffer_size_ext (Windows-style) would be better - a 1 at the
> end 1) is a bit unclear about what it means and 2) may look too much like an
> l (I first thought it *was* an "l", for "long", but maybe that's just the
> particular fixed-width font that's the default in macOS).
>
> (Or pcap_set_buffer_size_size_t, but that may be a bit awkward.)
>
I used '1' because that's what Linux does when advertising newer
versions of syscalls.
'_ext' does look better, I think I'd go with that.
> > 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.
>
> There should probably be an API to get the maximum buffer size as well, for
> the benefit of 1) programs that want "the biggest buffer they can get" and 2)
> GUI programs that might have a "buffer size" field implemented as a spinbox.
>
I thought about that after sending the RFC, and I think it's a good idea.
> Should pcap_set_buffer_size also check against the maximum size, and set it
> to the maximum size if it's above the maximum?
>
I'd like that, but I thought it'd be better to leave it as is to avoid
breaking existing programs that might rely on this check missing.
For the same reason, I avoided changing the check for positivity to
return an error, as I think libraries should provide mechanisms, not
policies, and silently deciding on a different behaviour is the
latter.
> > 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 it to a more
> > appropriate value for the platform.
> > In this RFC, Linux and DPDK are used as examples.
>
> Is there a maximum buffer size > INT_MAX for Linux?
>
It seems I forgot to commit the changes to pcap-linux.c. It did set
the maximum buffer size to SIZE_MAX as well.
> At least in macOS, and possibly in other BSD-flavored OSes, the sysctl
> variable debug.bpf_maxbufsize will indicate the maximum size.
I'm not sure how to handle this.
Buffer size can only be set before activation, but filters can be set
at any point.
From the user POV, I wouldn't like my buffers to be limited by the
maximum size of filters when I never use them.
However, another user may attempt to set it after using a buffer
exceeding this, and it would fail in mysterious ways.
The only solution I came up with is to always use software filters
when the buffer is too big.
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
