Re: [tcpdump-workers] [RFC PATCH] Add new `pcap_set_buffer_size1` API.
On Oct 2, 2019, at 6:40 PM, Mario Rugiero wrote: > El mié., 2 oct. 2019 a las 19:48, Mario Rugiero () > escribió: >> 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. > On the other hand, numeric versioning is more future-proof. > 'pcap_set_buffer_size_ext_ext_ext wouldn't look good. Any future extension would probably add another argument - I doubt there'd be a reason for a size argument bigger than a size_t - so presumably it's be setting something other than just the buffer size, and it'd be pcap_set_buffer_size_and_suitcase_size or something such as that, unless you could just have separate pcap_set_buffer_size_ext and pcap_set_suitcase_size calls. Either that, or there'd be options or a mode or something such as that, e.g. flags such as "if the size is too big, just clamp it at the maximum" or something such as that, in which case it'd be pcap_set_buffer_size_with_options. So I don't expect to have to go with pcap_set_buffer_size_ext_ext_ext or with pcap_set_buffer_size2. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] [RFC PATCH] Add new `pcap_set_buffer_size1` API.
On Oct 2, 2019, at 3:48 PM, Mario Rugiero wrote: > > El mié., 2 oct. 2019 a las 18:46, Guy Harris () 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 . >> 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
Re: [tcpdump-workers] [RFC PATCH] Add new `pcap_set_buffer_size1` API.
El jue., 3 oct. 2019 a las 4:28, Guy Harris () escribió: > > 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 . > That sounds good. Should we still allow passing buffers below that minimum with the original set_buffer_size? > >> 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. > Yes, I now realize Mac OSX mechanism for capture is also called BPF. Since it was brought up that BPF had buffer size issues, I assumed we were talking about somehow filtering and buffer size interacting. It did sound strange, but I'm more of a neophyte here so I just assumed everyday we learn something new :) ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] Legacy Linux kernel support
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. Anybody not upgrading the kernel for as long is very unlikely to want to update libpcap. The result is a code that is quite daunting and hard to debug and understand for newcomers (hi!), for what I see as little to no gain. I posted an issue in Github (#853) about this and thought it'd be better to discuss this here. While I'd like to do the work, I think it'd be most productive if I met any objection or suggestions before going through the work and making a PR. 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. 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. I think the module can benefit from a general cleanup. Examples of what I'd like to see removed are: TPACKET V1 and V2 handling. This includes some special casing for VLAN tags. SOCK_PACKET. All of it. 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. That was probably not an option before, but IIRC the first glibc to implement it became common ~2005. Anyway, I declare the debate open. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
