On Wed, Mar 29, 2017 at 04:28:24PM -0700, Guy Harris wrote:
> On Mar 29, 2017, at 2:04 PM, Joerg Mayer <jmayer@xxxxxxxxx> wrote:
>
> > does HAVE_REMOTE imply that libpcap supports pcap_create nowadays? If so, it would
> > allow some nice cleanups ;)
>
> On Windows, where we do checks at run time (as we load WinPcap dynamically) as well as compile time, older versions of WinPcap had pcap_open(), with remote support, but not pcap_create(); current versions have both. Our code is built with support for both; if the version of WinPcap we've loaded doesn't have pcap_create(), we fall back on pcap_open_live().
>
> On macOS, if we were to do run-time checking (so that we can support new features if, as, and when Apple picks them up), the oldest OS we support with our binary packages is Snow Leopard, which has pcap_create().
>
> On UN*X without run-time checking, the only releases from tcpdump.org that offer remote capture support will also have pcap_create(); you'd only have to worry about people who add remote capture to a pre-1.0 libpcap and build it and install it themselves, and I'm not sure worrying about them is worth it.
So it might be worth waiting for libpcap to unconditionally enable rpcap support
before getting rid of all the pcap_create #defines inside have_remote.
Thanks!
Jörg
--
Joerg Mayer <jmayer@xxxxxxxxx>
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.
