--- 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) and: 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 precision, 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: https://github.com/DNS-OARC/dnscap/blob/develop/src/dumper.c https://github.com/raybellis/libpcap-gzip 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 = pcap_ioplugin_init(getenv("PCAP_IOPLUGIN_READ")); 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 argument). 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 tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
