Re: Setting BPF_SPECIAL_VLAN_HANDLING on a "dead" handle

[Stephen Hemminger via tcpdump-workers <tcpdump-workers () lists tcpdump org>]

> --- Begin Message ---
>
>
> From: Stephen Hemminger <stephen () networkplumber org>
>
> Date: Tue, 8 Jul 2025 09:02:21 -0700
>
> On Fri, 4 Jul 2025 13:05:01 -0700
> Guy Harris <gharris () sonic net> wrote:
>
> > On Jul 4, 2025, at 8:55 AM, Bill Fenner <fenner () gmail com> wrote:
> >
> > > We may know that we will be using this code on a kernel that
> > > requires BPF_SPECIAL_VLAN_HANDLING, and so I'd like to be able to set that
> > > flag on a "dead" handle.  Obviously, the current mechanism is to test this
> > > dynamically when the handle is live.
> > >
> > > Does anyone have any opinions about how to implement this, through the
> > > generic pcap interface?  I can think of two possibilities:
> > >
> > > 1. implement set_special_vlan_handling_op, and have it implemented by dead
> > > and linux, and have the default version return an error
> > > 2. implement set_bpf_codegen_flags_op, and have a generic implementation,
> > > assuming that the caller completely knows what they are doing. Then move
> > > the definition of BPF_SPECIAL_VLAN_HANDLING from pcap-int.h to the public
> > > header.  
> >
> > The underlying problem is that we have a compiler with multiple targets, and the target is indicated by a pcap_t *.
> >
> > My inclination might be to have a version of pcap_compile() that takes, as additional arguments, a link-layer type, a 
> > snapshot, and a set of BPF_SPECIAL_ flags.
> >
> > That might be slightly cleaner than the bpf_open_dead() hack. Yes, it means that the caller has to know what they're 
> > doing, but they'd have to know that *anyway* - is the code intended for:
> >
> > * live captures with a Linux kernel without VLAN tag fetching support in BPF, in which case you want 
> > BPF_SPECIAL_BASIC_HANDLING;
> > * live captures with a Linux kernel *with* VLAN tag fetching support in BPF, in which case you want 
> > BPF_SPECIAL_BASIC_HANDLING|BPF_SPECIAL_VLAN_HANDLING;
> > * live captures with Npcap, in which case you want BPF_SPECIAL_VLAN_HANDLING;
> > * anything else, in which case you want 0.
> >
> > While we're at it, a new pcap_dump_open() routine that takes a link-layer type and a snapshot length might be worth 
> > introducing, rendering pcap_open_dead() mostly, if not completely, redundant.
> > _______________________________________________
> > tcpdump-workers mailing list -- tcpdump-workers () lists tcpdump org
> > To unsubscribe send an email to tcpdump-workers-leave () lists tcpdump org
> > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
> There is a related problem with use of pcap and BPF in DPDK.
> Current DPDK code use pcap_open_dead() and pcap_compile() to convert to cBPF, then converts that to eBPF.
> The problem is that it is impossible to look at metadata fields in the DPDK (negative offsets).
> To workaround that for now VLAN's are reinserted before running BPF.
>
> --- End Message ---
_______________________________________________
tcpdump-workers mailing list -- tcpdump-workers () lists tcpdump org
To unsubscribe send an email to tcpdump-workers-leave () lists tcpdump org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s