--- Begin Message ---
trying without GPG signature

{Hi, my email never made it through the list earlier.
Francois' email went through earlier today, so I am at a loss
as to what has happened.  And other lists worked.  I thought mailman was
stuck, but I dunno.  I backed up the list configuration, and list names, and
remade the list, and then I found other postfix vs mailman issues that seemed
to affect only lists hosted at lists.tcpdump.org.  Moving on, I hope}

We have:
   pcap_t *
   pcap_open_offline_with_tstamp_precision(const char *fname, u_int precision,
                                        char *errbuf)

  pcap_t *
  pcap_open_offline(const char *fname, char *errbuf)

and then we have:
 #ifdef _WIN32
  pcap_t* pcap_hopen_offline_with_tstamp_precision(intptr_t osfd, u_int 
      char *errbuf)

And we have a pull request
https://github.com/the-tcpdump-group/libpcap/pull/982 that I just rebased
that adds a "hidden" option.
Code originally from Ray Bellis, and a lot of the root DNS operators want this.
Note that this loads a .so file to do the work.
  Examples are at:

Ray went in that direction when we complained that distros might not want an
additional dependancy upon -lz or something else.

  { So I come to believe that I erred here: the dependancy upon -lz might have
    been better than this.  But.}

The pcap_open_offline() patched starts with:
        const pcap_ioplugin_t *plugin = 

And I really don't want to do it this way with the environment variable.
(Convince me otherwise....)

I really think that changing behaviour of programs via environment variables
is a recipe for security holes.   I would much happier if this was a --option
for tcpdump, and if anyone wants to pull it from an an environment variable
that they put that into the application rather than the library.

So I would prefer if the code instead did some new pcap_open_offline_with..(new 
Something that we could expand without continuing to make new functions!

For many things, the best situation is if we can do a pcap_set_XXX().
For timestamps, we didn't do that, because we need the precision in order to
help validate the pcap header.  Perhaps we could have done this another way.

For live captures, we have the sequence pcap_create/pcap_activate split,
and perhaps there is a way that we can make use of the same kind of flow.
(Note that the pcap(3) page is vague as to what things can be between
pcap_create() and pcap_activate)

Options that I see are:
  1) do nothing for input, we can solve this later.
     The major win is on output, and just create pcap_dump_compressed_open()
     for now.

  2) rework input and output so that a pcap_t */pcap_dumper_t * could be
     returned, uninitialized, accept some set_options, and then be activated.

  3) more extensive rework so that pcap_create() could create handle for
     live and offline captures, and that specifying the capture type was
     just another set.

These are not mutually exclusive.

]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     m...@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [

--- End Message ---
tcpdump-workers mailing list

Reply via email to