Re: [tcpdump-workers] [RFC PATCH] Add new `pcap_set_buffer_size1` API.
El mié., 2 oct. 2019 a las 18:46, Guy Harris () escribió: > > On Oct 2, 2019, at 2:16 PM, Mario Rugiero 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
Re: [tcpdump-workers] [RFC PATCH] Add new `pcap_set_buffer_size1` API.
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. ___ 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
Re: [tcpdump-workers] Legacy Linux kernel support
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.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. > > So what would be the oldest kernel that your revised code would support? > I'm reading 3.16? > Yes. Probably older, but as a side effect only, and I wouldn't like that support to be advertised. > > Anybody not upgrading the kernel for as long is very unlikely to want > > to update libpcap. > > Well, that's not really true. > There are many cases where people have to debug some silly appliance > that has been locked down to some 2.6 (or 2.4 due to binary blog drivers) > kernel. They often have to build libpcap/tcpdump elsewhere and copy the > binary over. > > Reasonably, though, they could probably build an old version of libpcap. > So, I would ask that the simplified code point to the last version of libpcap > (1.9) that will work in the error message. Your revision could be in 1.10. > That's reasonable. We could report it at runtime checking `uname` and at build time by checking `#ifdef`s and throwing a build time error. > > 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. > > Yes, so the USB sniffer is not in pcap-linux.c, but pcap-usb-linux.c, and I > don't think you propose to change that. > Indeed, I'm not proposing touching that. > > 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. > > +1 > > Now that 1.9.1 is out, now is a great time to do this. > I will attempt to crawl through pull requests that update pcap-linux.c, and > see if there is any low-hanging fruit that we should merge before you > cleanup. I will make some tag for this. You may want to go ahead of me, as I > won't start before oct. 14, probably finish wednesday Oct. 16. > Great, I'll try to start this week. > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Legacy Linux kernel support
> 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 something that can write
> out a pcap file to read on another machine.
>
> If nobody's still doing that, we might as well get rid of, for example,
> SOCK_PACKET support.
>
Even if they are, I'm not sure why they would want to update libpcap
in that case.
> > 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.
>
> Which behavior can only be defined at build time?
>
> The work-around itself is enabled or disabled based on the current running
> kernel version; see set_poll_timeout().
>
> The point there is that there isn't a version of the kernel that supports
> TPACKET_V3 on which we can't use TPACKET_V3, given the workaround.
>
Yes, I was typing faster than I was thinking. I meant at run-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.
>
> We don't #ifdef around whether the kernel on which we'll be *running* has
> TPACKET_V3.
>
> We #ifdef around whether the *headers with which we're building* have the
> #defines, structures, etc. needed to compile the code that supports
> TPACKET_V3.
>
Yes. This still makes for different builds, and this still means what
the kernel headers define may not match what the user has.
If we support only newer kernels at run-time, it makes sense that we
support only newer kernels at build-time.
> 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, and would require that
> the headers with which libpcap is being built be new enough to support
> TPACKET_V3.
>
Yes. That's what I'm proposing.
> 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
> buffer into userland), but:
>
> immediate mode is generally used for people (ab)using libpcap to
> implement protocols at the link layer, where you aren't necessarily dealing
> with the packet firehose you can get when doing sniffing;
>
Hmmm, I use memory-mapping precisely to deal with that fire hose
without dropping too much.
> memory-mapped mode means declaring a maximum-sized buffer for
> packets, so it may consume more memory for the buffering;
>
I could argue that declaring this maximum-sized buffer may give you
more control over the memory consumption instead.
> so non-memory-mapped capturing might be a better fit.
>
Isn't pcap currently using memory-mapping whenever it can?
> ("(Ab)using" in the sense that perhaps there should be a *separate* library
> for use by code implementing protocols that run directly atop the link layer;
> on some platforms - not just Linux - that code might use a completely
> different mechanism from the mechanism used by libpcap.)
>
That's a weird use-case indeed. I'm not sure libpcap is that bad of an
option for this.
> > SOCK_PACKET. All of it.
>
> Unless there are still important small embedded devices or whatever 1) for
> which there's a good reason to run a 2.0.x (or 1.x) kernel, 2) for which
> there's a need to run libpcap-based code on the device, and 3) on which
> they'd really want to build the Latest Newest Shiniest version of libpcap,
> yes, drop SOCK_PACKET support.
The thing is, we can never know that there aren't. We can only know
there are, if someone asks for support for them.
It's a leap of faith.
I think I'd rather just fix security bugs (easy to say, not being the
maintainer, heh) and backport them to some kind of LTS release than do
the main development with it polluting the code-base.
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Legacy Linux kernel support
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 passively sniff. The protocol idea is new to me. > How so? There's no way to specify, with TPACKET_V3, "deliver a block as soon > as there is a packet in it" (unless I've missed something), which is what > immediate mode means, so, for memory-mapped capturing in immediate mode, we > have to fall back on TPACKET_V1 or TPACKET_V2. > > With TPACKET_V1 or V2, the frame size is fixed, and must be >= the largest > amount of data you will get in a frame. If the frame is shorter than that, > there's wasted space. > > With TPACKET_V3, the frame size isn't fixed, so if you have a snapshot length > of 1514 bytes but the frame is only 60 bytes, you don't get 1454 bytes of > wasted space. > > >> so non-memory-mapped capturing might be a better fit. > > > > Isn't pcap currently using memory-mapping whenever it can? > > Yes, but *should* it do so for immediate mode? > Good time to discuss (and fix it?), then :) > In immediate mode, with TPACKET_V1 or V2, you have wasted space, as per the > above. With non-memory-mapped capture, you just get skbuffs attached to the > socket; I don't know if Linux has the equivalent of what the "loaned mbufs" > some BSD-style stacks have, where the skbuff would directly point to a driver > ring buffer slot, in which case there would probably still be wasted space > (and in which case, if you don't consume the packet quickly, the adapter > could run out of buffers), or if they're copied, in which case the target > skbuff might not be full sized and there'd be less wasted memory. > Hmmm, that makes sense. I thought the concern was about total memory use. Give me a day or two to check the sources on how the skbuff gets exposed. > One of the aforementioned impedance matches is that the protocol > implementation might want only one particular Ethernet type or one particular > OUI/PID combination for SNAP frames - that could be done with a packet > filter, but the OS mechanism might have a way to do it directly (binding to a > particular protocol with Linux PF_PACKET sockets, binding to a particular SAP > rather than setting SAP-promiscuous mode with DLPI, something else with the > *non-BPF* mechanism that may be a better fit for this in macOS). > > I'd have to find my notes from when I was looking at what an alternative > library might do to see what some of the other ones are. Interesting. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Legacy Linux kernel support
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, rather than passively > sniffing traffic, you still get a packet firehose? > >> > > No, I get a packet fire hose because I passively sniff. > > And presumably you're not doing that in immediate mode. (tcpdump > *currently* uses immediate mode if it's in sniff-and-print mode, but maybe > it should select a shorter timeout instead - and perhaps, these days, a > 1-second timeout is too much even if you're capturing to a file.) > I don't think so, but I should probably check. > > > The protocol idea is new to me. > > And that's where I'm saying we might want to use non-memory-mapped > capturing. I see. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Legacy Linux kernel support
El mar., 8 oct. 2019 a las 3:59, Michael Richardson () escribió: > There are many people who use prototype new things this way. > Even IP/IPv6 stuff that use a different protocol number. Often they move > away from libpcap as their requirements grow, but they start that way. > > One reason to do this because they don't control the kernel they have to run > on. > Supporting TPACKET_V2 should suffice to fill this gap, right? We would still need to make a few changes, currently you need to use a kernel which doesn't support TPACKET_V3 to use this correctly. It shouldn't be a big change to make immediate mode go with TPACKET_V2, so I guess I could do it. > While they may be using "old" kernels, they usually aren't using ancient > (jurasic) kernels. > What do we exactly mean when we talk about "old" and about "Jurassic"? 2.6.x would be old and 2.4.y would be Jurassic? El mar., 8 oct. 2019 a las 7:58, David Laight () escribió: > I don't think it makes sense to drop support for kernels which distributions > still have under LTS. > I think that means 2.6.32 still needs to be supported. > It depends. Which distro is it? When does it EOL? Do we expect a release of libpcap before that? What version of libpcap does it ship? Do the providers ship it with custom patches? For the "official" distro package, is it likely to have a major upgrade? Do they currently provide bug-fixes on their own Is it simpler to just branch away for critical fixes? Note that patches will be backported one way or another if they don't do major upgrades. Considering it's an LTS, I'm guessing they don't do major upgrades and they keep vendor patches already, so that's what they'll keep doing. Is it a good idea for a user to do a custom build? Are there any life changing features between then and now that can actually be used with an old kernel? Is it worthy losing the support you paid for for it? The latter can obviously only be answered by the users, but since making a census is rather impractical, I think we should make guesstimates here. El mar., 8 oct. 2019 a las 12:42, Michael Richardson () escribió: > And that's why I think we would agree that we don't want to let tcpdump go > all C99, etc. yet, because people often *do* want the latest tcpdump, on top > of a kernel-compatible libpcap. > That's why we use abstraction layers, after all. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Legacy Linux kernel support
El mar., 8 oct. 2019 a las 13:29, Mario Rugiero () escribió: > It depends. > Which distro is it? > When does it EOL? > Do we expect a release of libpcap before that? > What version of libpcap does it ship? > Do the providers ship it with custom patches? > For the "official" distro package, is it likely to have a major upgrade? > Do they currently provide bug-fixes on their own > Is it simpler to just branch away for critical fixes? Note that > patches will be backported one way or another if they don't do major > upgrades. > Considering it's an LTS, I'm guessing they don't do major upgrades and > they keep vendor patches already, so that's what they'll keep doing. > Also, I just checked, 2.6.32 supports TPACKET_V2, which should still be supported because of immediate mode. So we can make them happy, too. I still dislike the idea of advertising such support, tho, as it may imply a compromise to add workarounds and such if they eventually need them, and that generally is a slippery slope. El mar., 8 oct. 2019 a las 14:24, Guy Harris () escribió: > cp /dev/null patch > > should suffice. :-) > > I.e., we're *already* using TPACKET_V2 if immediate mode is specified. See > prepare_tpacket_socket() - if handle->opt.immediate is set, it doesn't try > TPACKET_V3, and skips to TPACKET_V2. Cool! I must have missed it. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Legacy Linux kernel support
El mar., 8 oct. 2019 a las 18:16, Michael Richardson () escribió: > So I'm hearing that on Linux we should support V2 and V3. > *That we continue to need V2 support from the kernel for immediate mode* > I think so, yes. > (This has implications to the *kernel* people as to what they can rip out, > and we should try to find a plan going forward that reduces code for both of > us) > Well, they can rip out whatever they want, we would just be unable to support that on newer kernels. They are very unlikely tho, due to their policy of not breaking userspace (whenever possible). If I understand correctly, the current state of affairs is that TPACKET_V3 is unsuitable for immediate mode. I'll try to research a bit more on this in the next few days, but I'm inclined to believe you and Guy know better about it. We could try and work something out with the kernel bunch to make it suitable, but I don't think I know enough to push that forward by myself. Maybe (haven't checked) TPACKET_V4 can be used, but I think that's too recent to require from downstream to get immediate mode working. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Legacy Linux kernel support
El mié., 9 oct. 2019 a las 13:16, Michael Richardson () escribió: > Right, but the different mechanisms can be different modules, and distros can > opt not to even build the modules, and eventually we can all move forward. > But that wouldn't make any difference maintenance wise that I can see. > It would be worth opening a dialogue on how to get immediate mode with _V3 > (or _v4). > I agree. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Legacy Linux kernel support
--- Begin Message --- I think it's time to summarize, and to propose one last idea. I'm following the thread again to try and be as accurate as possible, but of course any objections are welcomed. - The oldest officially supported kernel is 3.16, as this is the oldest LTS according to kernel.org. - Users of the library must be properly informed when their environment is unsupported, as well as the last version supporting it. This should be done both at compile-time and at run-time. - SOCK_PACKET goes away. This is already done in master. - TPACKET_V1 goes away. - TPACKET_V2 stays for immediate-mode support. - As a side-effect, RHEL6 remains supported. - The idea of exploring using non-memory-mapped sockets for this was proposed, and it would be interesting to follow-up. For this, I was supposed to check whether that makes a difference regarding how the kernel implements it. - The workaround for TPACKET_V3's bug stays, as the fix was only introduced in 3.19. - We should explore reaching a solution to immediate-mode that doesn't require TPACKET_V2. - It has to be noted, tho, that any changes to allow that aren't unlikely to be back-ported to older kernels, so we'd still need TPACKET_V2 for the time being. It'd be a bet for the future. - Just to acknowledge it, it was proposed to research on whether support for AF_XDP makes sense. I think that belongs to its own discussion, tho. Now, the idea goes along with the last item. I was thinking of proposing a new option for TPACKET_V3 sockets to set a deadline. I haven't completely decided on the details, but basically it would behave somewhat like this: - The deadline can take three types of value: - (-1): no deadline, wait until a block is full before marking as ready for user space. This would be the default, so no existing programs change their behavior. - (0): expose packets as soon as they arrive. This would act more or less as previous AF_PACKET versions work. - A positive integer: this would be how long to wait (I haven't decided on the unit, I'm guessing microseconds should work). I'm not sure regarding what the deadline is set, but I'm thinking since the first packet in the block arrived. Any ideas on this? How should we keep the discussion in sync between the two lists? Should I CC the participants on this list on the RFC on the kernel list? --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Legacy Linux kernel support
--- Begin Message --- El mar., 22 oct. 2019 a las 15:08, Guy Harris () escribió: > > On Oct 21, 2019, at 5:59 PM, Mario Rugiero via tcpdump-workers > wrote: > > - TPACKET_V2 stays for immediate-mode support. > > - As a side-effect, RHEL6 remains supported. > > So RHEL6's kernel is pre-3.16 and thus doesn't support TPACKET_V3? > It's 2.6 series (2.6.32?), and TPACKET_V3 was introduced in 3.2. > > - We should explore reaching a solution to immediate-mode that doesn't > > require TPACKET_V2. > > - It has to be noted, tho, that any changes to allow that aren't > > unlikely to be back-ported to older kernels, so we'd still need > > TPACKET_V2 for the time being. It'd be a bet for the future. > > So you're talking about a TPACKET_V5, or changes to TPACKET_V3 or TPACKET_V4, > to support immediate mode in memory-mapped capture, as opposed to using > non-memory-mapped sockets? > I was thinking more of a backwards compatible extension to TPACKET_V3 in principle, but that's open for discussion. My thoughts on this are at the end of my summary. > > - Just to acknowledge it, it was proposed to research on whether > > support for AF_XDP makes sense. I think that belongs to its own > > discussion, tho. > > Yes, that's a different mechanism from AF_PACKET. > > Does it allow receiving copies of packets that are also handed either to the > kernel networking stack or to other AF_XDP sockets for regular input > processing? That would be needed to allow it to be used for packet sniffing. > I haven't looked into it yet, but I'll keep that in mind when I do. > > Now, the idea goes along with the last item. > > I was thinking of proposing a new option for TPACKET_V3 sockets to set > > a deadline. > > I haven't completely decided on the details, but basically it would > > behave somewhat like this: > > - The deadline can take three types of value: > > - (-1): no deadline, wait until a block is full before marking as > > ready for user space. This would be the default, so no existing > > programs change their behavior. > > That sounds like the behavior with a timeout set to 0 (with PF_PACKET > sockets, BPF devices, and Solaris DLPI) > > > - (0): expose packets as soon as they arrive. This would act more or > > less as previous AF_PACKET versions work. > > That sounds like immediate mode. > > > - A positive integer: this would be how long to wait > > If you mean "deliver a block if it's full or if the timeout expires", that > sounds like the behavior with a non-zero timeout. > > So how does this differ from the regular timeout mechanism? > This mechanism would be for the AF_PACKET driver in the Linux kernel, not for libpcap. libpcap would only either set a small non-zero deadline on TPACKET_Vx (x >= 3) or 0 for immediate mode, and just use the default behavior for non-immediate mode. The similarity with what libpcap does is not a coincidence. > > (I haven't decided on the unit, I'm guessing microseconds should work). > > The units are milliseconds in pcap_set_timeout() and with BPF devices. > Yes, but for spacing between packets milliseconds may be to coarse. > >I'm not sure regarding what the deadline is set, but I'm thinking > > since the first packet in the block arrived. > > At least for BPF devices, it's "since a read or select was done", rather than > "since the first packet in the block arrived"; I think it might be "since the > first packet in the block arrived" with Solaris DLPI. > I should read that for inspiration, then. > > Any ideas on this? > > How should we keep the discussion in sync between the two lists? > > Should I CC the participants on this list on the RFC on the kernel list? > > "The two lists" being this list and some Linux list? > > Is the Linux list linux-netdev? Yes. Addendum: I missed one, replacing some device detection boilerplate. Initially. `if_nameindex` was proposed, but there's already the `getifaddr` based implementation that should detect all Linux interfaces usable by pcap by 2.3.x due to the fact that it counts AF_PACKET addresses, so we should be able to just remove the '/proc/net' and '/sys/class/net' crawling when we start expecting 2.4. --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Legacy Linux kernel support
--- Begin Message ---
El mar., 22 oct. 2019 a las 16:02, Guy Harris () escribió:
> I.e., the goal for libpcap support on Linux should be something such as
>
> it should work on min({kernel for oldest supported enterprise
> distribution}, {oldest "longterm maintenance" kernel release from kernel.org})
>
I'm more inclined to oldest longterm from kernel.org only, but I guess so.
> OK, so TPACKET_V3 currently supports something similar to what BPF devices
> support, i.e. "deliver a block if it's full or if the timeout expires". The
> timeout is in the tp_retire_blk_tov field of a tpacket_req3 structure, as
> handed to a SOL_PACKET/PACKET_RX_RING setsockopt() call. It's in units of
> milliseconds; it doesn't refer to inter-packet spacing, but to the age of the
> block.
>
> Currently it doesn't deliver empty blocks; libpcap can handle either
> "delivers empty blocks" (as that's what BPF devices do) or "doesn't deliver
> empty blocks" (as that's what TPACKET_V3 currently does).
>
> The main difference is whether the timeout times out even if no packets are
> available; I guess code that wants to be woken up periodically, perhaps to do
> other work, even if there's no traffic that passes the filter would prefer
> "time out even if no packets are available".
>
I see. We would want a way to signal we want time outs regardless of
blocks being empty, then, right?
> OK, I guess I'll have to go back to reading that list. (It's a very heavy
> traffic list, and 99.999% of it isn't relevant to packet capture -
> all that matters to me is 1) PF_PACKET stuff and 2) stuff involving device
> modes such as some ethtool features and monitor-mode/radiotap support - so I
> just look at it on occasion.)
>
Wouldn't CC'ing you keep you on the loop already?
> I.e., getifaddr() will find interfaces with no networking-layer addresses (no
> IPv4/IPv6/etc.) on 2.4 and later kernels?
>
Exactly. There's even a code sample showing this in the Linux manual.
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Legacy Linux kernel support
--- Begin Message --- El mar., 22 oct. 2019 a las 18:01, Guy Harris () escribió: > > If RHEL 6 matters, oldest longterm from kernel.org only doesn't work, because > RHEL 6 runs 2.6.32, according to > > https://access.redhat.com/articles/3078 > > so if we're going to support only the oldest longterm maintenance kernel from > kernel.org, we're not going to support RHEL 6 unless TPACKET_V3 has been back > ported to the RHEL 6 kernel. > > If it's not backported, *and* we continue to use TPACKET_V2 for immediate > mode, then RHEL 6 happens to still be supported to that extent. > > However, if we require any *other* mechanisms that aren't present in the RHEL > 6 kernel, that means no RHEL 6 support. > > So I wouldn't claim RHEL 6 support solely on the basis of continued > TPACKET_V2 support - don't rely on the side effect. > Exactly. I'm against supporting it if it requires extra work. I don't think libpcap 1.10 is an absolute need in a scenario where you have to deal with RHEL 6, except possibly for security fixes, but those will have to be backported by Red Hat anyway. > Either that, or just change TPACKET_V3 to do that. > Yes, that's what I was proposing. > Originally, TPACKET_V3 delivered wakeups in a bogus fashion: > > ... > > The code currently has the patch, and doesn't deliver empty blocks. > I'll read these carefully later, but my take on it is that TPACKET_V3 used to support our use case, so in principle a patch to restore it could be accepted. I find it unclear whether it is the ability of posting of empty blocks that would break use cases or its absence from the previous paragraph, but I guess I'll know after reading the mails. > It doesn't look as if you've sent anything to netdev yet about tpacket > changes. > I haven't, I wanted to discuss this here first. --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Legacy Linux kernel support
--- Begin Message --- El lun., 2 mar. 2020 a las 14:31, Michael Richardson () escribió: > I am trying to process many pull requests for libpcap and tcpdump, get some > things closed. I don't think that there is a pull request from you yet. > Am I wrong? > Some related PRs got merged already. My Github user may be misleading, but I'm Oppen. I think those cover most of the least controversial aspects of this thread. I may try to cover more of them later. > Are you still up for this work? > Yes, I'd be glad to keep working on this. --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Legacy Linux kernel support
--- Begin Message --- El mar., 10 mar. 2020 15:07, Michael Richardson escribió: > > Mario Rugiero wrote: > >> I am trying to process many pull requests for libpcap and tcpdump, > get some > >> things closed. I don't think that there is a pull request from you > yet. > >> Am I wrong? > > > Some related PRs got merged already. My Github user may be > misleading, > > but I'm Oppen. > > Aha! > > > I think those cover most of the least controversial aspects of this > thread. > > I may try to cover more of them later. > > >> Are you still up for this work? > >> > > Yes, I'd be glad to keep working on this. > > okay, I was looking through the pcap-linux.c on master, and I was > like... OMG... gotta make this better. > > Do you happen to know if the 3.19 fixes are back ported in RHEL7 to their > 3.10 kernel stream? I can't check, but I don't think so. >Or rather, should I expect TPACKET_v3 to work correctly > on RHEL7? > Same. We still have TPACKET_V2 for both immediate mode and older kernels, tho. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Legacy Linux kernel support
--- Begin Message --- El mar., 10 mar. 2020 15:26, Mario Rugiero via tcpdump-workers < tcpdump-workers@lists.tcpdump.org> escribió: > > > > -- Forwarded message ------ > From: Mario Rugiero > To: Michael Richardson > Cc: tcpdump-workers > Bcc: > Date: Tue, 10 Mar 2020 15:25:38 -0300 > Subject: Re: [tcpdump-workers] Legacy Linux kernel support > El mar., 10 mar. 2020 15:07, Michael Richardson > escribió: > > > > > Mario Rugiero wrote: > > >> I am trying to process many pull requests for libpcap and tcpdump, > > get some > > >> things closed. I don't think that there is a pull request from > you > > yet. > > >> Am I wrong? > > > > > Some related PRs got merged already. My Github user may be > > misleading, > > > but I'm Oppen. > > > > Aha! > > > > > I think those cover most of the least controversial aspects of this > > thread. > > > I may try to cover more of them later. > > > > >> Are you still up for this work? > > >> > > > Yes, I'd be glad to keep working on this. > > > > okay, I was looking through the pcap-linux.c on master, and I was > > like... OMG... gotta make this better. > > > > Do you happen to know if the 3.19 fixes are back ported in RHEL7 to their > > 3.10 kernel stream? > > I can't check, but I don't think so. > Sorry, I meant to say that I *do can* check. > > >Or rather, should I expect TPACKET_v3 to work correctly > > on RHEL7? > > > Same. We still have TPACKET_V2 for both immediate mode and older kernels, > tho. > > > > > -- > > Michael Richardson , Sandelman Software Works > > -= IPv6 IoT consulting =- > > > > > > > > > > > > -- Forwarded message -- > From: Mario Rugiero via tcpdump-workers > > To: Michael Richardson > Cc: tcpdump-workers > Bcc: > Date: Tue, 10 Mar 2020 14:24:48 -0400 (EDT) > Subject: Re: [tcpdump-workers] Legacy Linux kernel support > ___ > tcpdump-workers mailing list > tcpdump-workers@lists.tcpdump.org > https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers > --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Legacy Linux kernel support
--- Begin Message --- Hi again. I'm not sure I'm reading it right (thus I ask here), but is this[0] the fixing commit? If it is, I think it's applied on CentOS 7, and since it's basically a free rebuild of RHEL, I'd expect it to be fixed there, too. I'll send a few links later so you can check it out after you either confirm or discard it. [0]: https://github.com/torvalds/linux/commit/41a50d621a321b4c15273cc1b5ed41437f4acdfb --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] New RFCs for 1) pcap file format and 2) rpcapd protocol?
--- Begin Message --- El sáb., 21 mar. 2020 18:15, Guy Harris via tcpdump-workers < tcpdump-workers@lists.tcpdump.org> escribió: > 1) has the slight disadvantage that the name for the team suggests it's > for pcapng only; it appears that teams can be renamed: > > > https://help.github.com/en/github/setting-up-and-managing-organizations-and-teams/renaming-a-team > > Were we to rename it, I don't know what would be a good new name. > I'd be careful with this option, as it may affect downstream projects, as some download links that may be used for automated download (as part of a build process) could break. If there's anything downloadable I wouldn't change the team's name unless we make sure the old links remain accessible. --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Legacy Linux kernel support
--- Begin Message --- OK, follow up. I haven't yet been able to test it, which is why I've been delaying writing about this, but these two commits[0][1], which according to these threads[2][3] are the ones fixing the timeout issue, have been applied to CentOS 7 default kernel, 3.10.0-1062.el7. It can also be seen by comparing vanilla 3.10[4] with the CentOS sources[5], diffing the files located at net/packet/af_packet.c. This *should* mean it works without the workaround. I'd like to try it, but I'm currently fighting with VirtualBox guest additions and in a metered connection (I have no home connection and my country is in quarantine), so I'm being rather careful on my data usage. Now, if this is deemed insufficient, I have a test in mind that I may as well have early feedback on, with the following setup: - libpcap with the workaround removed; - vanilla and CentOS' kernels alternated; - a 2MiB packet ring; - a 64kiB block size and snaplen; - timeout of 8ms; - injection to a virtual interface at 1 packet every 20ms; - a simple application that reads and do nothing on its peer. I think that should give as a buffer small enough and a frequency low enough to fill the buffer and result in observable packet loss. Does it make sense? Any suggestions or criticisms to the setup? Is it necessary? [0]: https://github.com/torvalds/linux/commit/da413eec729dae5dcb150e2eb34c5e7e5e4e1b49 [1]: https://github.com/torvalds/linux/commit/41a50d621a321b4c15273cc1b5ed41437f4acdfb [2]: https://www.mail-archive.com/netdev@vger.kernel.org/msg163532.html [3]: https://www.mail-archive.com/search?l=net...@vger.kernel.org&q=subject:%22TPACKET_V3+timeout+bug%5C%3F%22&o=newest&f=1 [4]: https://cdn.kernel.org/pub/linux/kernel/v3.x/linux-3.10.tar.xz [5]: http://vault.centos.org/7.7.1908/os/Source/SPackages/kernel-3.10.0-1062.el7.src.rpm --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Legacy Linux kernel support
--- Begin Message --- OK, it seems fair. Besides, I just checked the code for the oldest long-term release from kernel.org, a 3.16 one, and it doesn't contain the fix, and I think it should be supported. --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] some questions about TPACKET3
--- Begin Message ---
El sáb., 27 jun. 2020 a las 23:56, Michael Richardson
() escribió:
>
>
> Mario, can you confirm my understanding here.
>
Hi Michael.
> In TPACKET3 mode, there are (tp_block_nr) pools of memory.
> The beginning of each block is tp_block_size in size, which can
> be large numbers like 4M in size. (2^22 in the kernel documentation example).
> (We, however seem to pick a blocksize which is only just big enough to hold
> the maximum snaplen.)
>
> Each one has a linked-list of tp3_hdr, which are interleaved with the packet
> data itself. The "next" pointer is the tp_next_offset.
> It seems from my reading of code that the kernel returns an entire chain
> of tp3_hdr to us, controlled by a *single* block_status bit.
> That is, we get entire chains of tp3_hdr from the kernel, and we return
> them to the kernel in single blocks.
>
> I think that this was not the case with tp2: in that packets were passed
> to/from the kernel one at a time, each one with their own TP_STATUS_KERNEL
> bit.
>
AFAIK all of this is correct.
> For a contract, I am trying to improve the write performance by using
> async I/O. {I also need to associate requests and responses, which makes the
> ordering of operations non-sequential}
> I therefore do not want to give the blocks back to the kernel until the
> write has concluded, and for this I'm working on a variation of
> linux_mmap_v3(), which will callback with groups of packets, through
> a pipeline of "processors", each of which may steal the packet, and
> then return it later.
>
> I am realizing that I have to keep track of the blocks, not just the
> packets. I guess my original conceptual thinking was too heavily
> influenced by V2, and I was thinking that V3 had changed things by
> splitting the hdr from the packet, putting the constant-sized hdrs
> into a fixed sized ring, while the packet content was allocated
> as needed.
> I see that I am mistaken, but I'd sure love confirmation.
>
I believe you may be thinking of AF_XDP. As you probably know, libpcap doesn't
have support for it (yet), but I don't think you'll have trouble using
it directly.
I worked briefly with the RX side of it, so I may be able to help you with that.
As you said, it splits headers from packets, sort of.
The packet contents are stored in blocks of a buffer called UMEM. Contrary to
PACKET_MMAP, you work with two queues per path, both containing descriptors
to find the data in UMEM. These descriptors fit the role of the headers.
For the RX side you have the FILL queue, where you store descriptors to indicate
the kernel a given block is free to use, and the RX queue, where the
kernel gives
these blocks back when a packet passes the filter[0].
The TX side has a TX queue, where you store descriptors pointing to the data you
want to send in the UMEM buffer, and a COMPLETION queue, where the kernel
gives you the blocks back for reuse after the data was sent.
IIRC, AF_XDP allows queuing packets to later send in a burst on
request, but since
I didn't work with that path, so I'm not 100% certain.
Since the UMEM blocks are fixed size and one block is used for each packet, they
consume more memory, but are much simpler to use for this and allows
out-of-order
release of resources.
[0]: AF_XDP requires eBPF filters to be installed in the kernel.
> I am also considering rewriting packet_mmap.txt :-)
>
> --
> ] Never tell me the odds! | ipv6 mesh networks [
> ] Michael Richardson, Sandelman Software Works|IoT architect [
> ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails
> [
>
>
>
>
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] some questions about TPACKET3
--- Begin Message ---
El dom., 28 jun. 2020 a las 18:02, Michael Richardson
() escribió:
>
>
> Mario Rugiero via tcpdump-workers wrote:
> >> For a contract, I am trying to improve the write performance by using
> >> async I/O. {I also need to associate requests and responses, which
> makes the
> >> ordering of operations non-sequential}
> >> I therefore do not want to give the blocks back to the kernel until the
> >> write has concluded, and for this I'm working on a variation of
> >> linux_mmap_v3(), which will callback with groups of packets, through
> >> a pipeline of "processors", each of which may steal the packet, and
> >> then return it later.
> >>
> >> I am realizing that I have to keep track of the blocks, not just the
> >> packets. I guess my original conceptual thinking was too heavily
> >> influenced by V2, and I was thinking that V3 had changed things by
> >> splitting the hdr from the packet, putting the constant-sized hdrs
> >> into a fixed sized ring, while the packet content was allocated
> >> as needed.
> >> I see that I am mistaken, but I'd sure love confirmation.
>
> > I believe you may be thinking of AF_XDP. As you probably know, libpcap
> doesn't
> > have support for it (yet), but I don't think you'll have trouble using
> > it directly.
>
> Ah!
> That explains some of my confusion. That's interesting to understand though.
> Please confirm that your explanation below is about AF_XDP, not V3 :-)
>
Yes, all below is AF_XDP :)
> Can you confirm that V3 works the way I think?
> We want to support AF_XDP eventually.
> Maybe we should support V2 for legacy and XDP for future.
> Hmm.
>
If you can pay the overhead, maybe V3 with some metadata for reference
counting could do the trick. You would decrement the counter just before sending
the matching packet, and release the block when it hits 0. What do you think?
> --
> ] Never tell me the odds! | ipv6 mesh networks [
> ] Michael Richardson, Sandelman Software Works|IoT architect [
> ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails
> [
>
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
