On Oct 2, 2019, at 3:48 PM, Mario Rugiero <mrugi...@gmail.com> wrote: > > El mié., 2 oct. 2019 a las 18:46, Guy Harris (<ghar...@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
