On Jul 4, 2025, at 8:55 AM, Bill Fenner <fen...@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-le...@lists.tcpdump.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

Reply via email to