Re: Setting BPF_SPECIAL_VLAN_HANDLING on a "dead" handle

[Guy Harris <gharris () sonic net>]

On Jul 8, 2025, at 7:36 AM, Denis Ovsienko <denis () ovsienko info> wrote:

> The need to have a pcap_t at all times is very similar to using file
> descriptors or sockets: first you obtain a descriptor, then you
> initialise it in various ways as necessary, then you have a very small
> number of methods to read and to write, and by that time the only
> things you need to specify are the descriptor and details of this
> particular read/write (how many bytes, location, blocking/non-blocking).

Yes, but is there a notion of a file descriptor for an "object" whose sole purpose is to, for example, fill in a stat 
structure when you call stat() on it, and supports no other operations?  A "dead" pcap_t's only purpose is to supply a 
link-layer type and snapshot length - and, potentially, compiler target type - to APIs that, for whatever reason, 
weren't designed to take those values as arguments.

> libcurl and other libraries implement a very similar approach using
> contexts and options, and quite often a new option is a much better
> solution than a new API function.

That's a question of options vs. API functions, with generic "add an option of this type" calls rather than adding a 
new API for each new setting. Michael Richardson's pcap_options API in the main branch should be expanded to 1) provide 
options as alternatives for the current APIs, 2) allow querying which options are available for a given pcap_t, and 3) 
allow a particular pcap module to provide its own private options for cases where it's medium-specific or 
mechanism-specific.

The generated-code type flags are specific to pcap_open_dead() - savefiles would just use "generate normal cBPF" 
(unless we add a BSD-licensed eBPF interpreter and use *that* for savefiles), capture devices would use whatever is 
appropriate for the device, and only "generate code for something that's neither a savefile nor a capture device", i.e. 
something opened with pcap_open_dead(), should support that option.

The pcap_options API supports an option set, so an alternative would be to pass an option set to a new "compile this 
filter expression" API without having to have a pcap_t to open and close.
_______________________________________________
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