Re: [RFC PATCH] Add new `pcap_set_buffer_size1` API.

[Guy Harris <gharris () sonic net>]

On Oct 2, 2019, at 3:48 PM, Mario Rugiero <mrugiero () gmail com> wrote:
> El mié., 2 oct. 2019 a las 18:46, Guy Harris (<gharris () sonic net>) escribió:
>
> > 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.

We might want to have another API to supply the *minimum* buffer size.  For BSD-style BPF, we could use BPF_MINBUFSIZE 
if it's defined in <net/bpf.h>.

> > 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.

That's the maximum *buffer* size.  We can just return that value as of the time when the pcap_create() is done.  Yes, 
there's a risk that it might be changed after it's fetched, but the chances of that are probably small; we could have a 
maximum_buffer_size_op pointer, and call p->maximum_buffer_size_op(p) rather than fetching the value from the pcap_t.

The maximum *filter* size is, at least in macOS High Sierra, hardwired at 512 instructions.

The two sizes are independent; as far as I know, they're independent in Linux as well (filters aren't part of 
PF_PACKET, they're part of the socket mechanism) and in all other in-kernel capture mechanisms.

> From the user POV, I wouldn't like my buffers to be limited by the
> maximum size of filters

They wouldn't be.

> However, another user may attempt to set it after using a buffer
> exceeding this, and it would fail in mysterious ways.

If a user were to change debug.bpf_maxbufsize, that would only affect *subsequent* attempts to set up a BPF device; it 
wouldn't affect existing devices.

> The only solution I came up with is to always use software filters
> when the buffer is too big.

No need to use software filters in that case.

And I think we *already* use software filters if the *filter* is too big.

_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers