Re: Legacy Linux kernel support

[Guy Harris via tcpdump-workers <tcpdump-workers () lists tcpdump org>]

> --- Begin Message ---
>
>
> From: Guy Harris <gharris () sonic net>
>
> Date: Tue, 22 Oct 2019 12:02:18 -0700
>
> On Oct 22, 2019, at 11:38 AM, Mario Rugiero <mrugiero () gmail com> wrote:
>
> > 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.
>
> 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})
>
> > > > 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.
>
>         ...
>
> > > 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.
>
> 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".
>
> > > Is the Linux list linux-netdev?
> >
> > Yes.
>
> OK, I guess I'll have to go back to reading that list.  (It's a very heavy traffic list, and 99.99999999999% 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.)
>
> > 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.
>
> I.e., getifaddr() will find interfaces with no networking-layer addresses (no IPv4/IPv6/etc.) on 2.4 and later kernels?
>
>
> --- End Message ---
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers