Re: Legacy Linux kernel support

[Mario Rugiero via tcpdump-workers <tcpdump-workers () lists tcpdump org>]

> --- Begin Message ---
>
>
> From: Mario Rugiero <mrugiero () gmail com>
>
> Date: Tue, 22 Oct 2019 15:38:50 -0300
>
> El mar., 22 oct. 2019 a las 15:08, Guy Harris (<gharris () sonic net>) escribió:
> > On Oct 21, 2019, at 5:59 PM, Mario Rugiero via tcpdump-workers <tcpdump-workers () lists tcpdump org> 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