Re: pcap_open_offline_... and options and the like

[Michael Richardson via tcpdump-workers <tcpdump-workers () lists tcpdump org>]

> --- Begin Message ---
>
>
> From: Michael Richardson <mcr () sandelman ca>
>
> Date: Sat, 19 Dec 2020 23:42:18 -0500
>
> Michael Richardson via tcpdump-workers wrote:
>     > trying without GPG signature
>
> YUP. That's it.  So mailman2 will have to get replaced finally.
> It eats emails with signature attachments, I think.  This is new.
>
> After a few hours thinking about my previous email I wanted to reply about my
> current thinking, and then was surprised not to see my email having got
> through.
>
> The distro on my list machine doesn't have mailman3, so maybe it is getting
> upgraded too!.
>
> In https://github.com/the-tcpdump-group/libpcap/pull/983
> Guy asked:
>
> guy> "Would affect" as in "those would be changed in separate commits"?
>
> guy> This is similar to some stuff I've been thinking about, based on
> guy> some long-ago requests for device-specific options.
>
> guy> The stuff I've been working on gave a name and description for
> guy> each option; the name is for use on the command line, e.g. with a
> guy> --capture-option flag, e.g. --capture-option channel=XXX, and the
> guy> description would be for use in 1) GUI applications such as Wireshark
> guy> and 2) a --show-capture-options flag that would give a list, for a given
> guy> device, of the available options, giving the name and the description.
>
> guy> Presumably:
>
> guy> this would affect pcap_init() by having a set of global pcap options to
> guy> apply (in an argument to pcap_init()?;
>
> guy> this would affect 'pcap_activate()by having a per-device list of
> guy> options, with calls to set the options being made afterpcap_create()and
> guy> beforepcap_activate()`;
>
> guy> this would affect pcap_open_offline() by having something such as a
> guy> pcap_open_offline_with_options() call that takes a list of options as an
> guy> argument;
>
> guy> this would affect pcap_dump_open*() by having similar
> guy> pcap_dump_open*_with_options() routines.
> guy> There would presumably be calls to indicate which options are available for a particular context.
>
> To which I replied:
>
> > The stuff I've been working on gave a name and description for each option;
> > the name is for use on the command line, e.g. with a --capture-option flag,
> > e.g. --capture-option channel=XXX, and the description would be for use in
> > 1) GUI applications such as Wireshark and 2) a --show-capture-options flag
> > that would give a list, for a given device, of the available options,
> > giving the name and the description.
>
> I think that it could support such use case with some additional calls.
> There is perhaps a chicken and egg issue with not knowing which options apply
> until a device has been selected.
> But at least, compile time options in libpcap would become apparent.
>
> > There would presumably be calls to indicate which options are available for a particular context.
>
> yes, I think so.
> See what I roughed out in this pull request, which is the minimum I think I
> need to do the ioplugin.
> Strings and integers and an ENUM. Maybe we want to have a call to find out if
> an enum is valid (i.e. not #ifdef out).
>
> --
> ]               Never tell me the odds!                 | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
> ]     mcr () sandelman ca  http://www.sandelman.ca/        |   ruby on rails    [
>
>
>
> --- End Message ---
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers