--- Begin Message ---
On Oct 22, 2019, at 11:38 AM, Mario Rugiero <mrugi...@gmail.com> wrote:
> El mar., 22 oct. 2019 a las 15:08, Guy Harris (<ghar...@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
