On Sat, Nov 11, 2017 at 10:25 AM, Guy Harris <guy@xxxxxxxxxxxx> wrote:
> On Nov 11, 2017, at 9:55 AM, Richard Sharpe <realrichardsharpe@xxxxxxxxx> wrote:
>
>> Hmmm, the problem really seems to be that my dev environment fails to
>> find pcap_open so it cannot support rpcap.
>>
>> That is, both HAVE_PCAP_OPEN and HAVE_PCAP_REMOTE are not defined, but
>> HAVE_PCAP_REMOTE is not defined because HAVE_PCAP_OPEN is not defined.
>>
>> Now to see if a more recent version of libpcap that 1.5.3 has what I need.
>
> I infer from "libpcap" that this isn't WinPcap and thus this isn't Windows.
>
> Until recently, rpcap support was not a standard part of libpcap.
>
> The tip of the libpcap master branch (1.9.0-PRE-GIT) does include libpcap support, but it's not configured in by default on UN*X, as I haven't audited the code to make sure it has no buffer overflow risks or other security issues. If you configure it with autotools, you have to configure with --enable-remote; if you configure it with CMake, you have to configure it with -DENABLE_REMOTE=YES. (Yes, CMake; I added CMake support to have something that handles building both on UN*X and on Windows. I also plan to add CMake support to tcpdump at some point.)
Yeah. Linux.
I notice that the latest libpcap git repo calls pcap_open_rpcap from
pcap_open_live ... but I did not check if that is available in 1.5.3
that I have on my dev VM ...
Anyway, assuming that those things work (for some value of "work") the
real problem is that the test in Wireshark's acinclude.m4 only checks
for pcap_open and not pcap_open_live ...
However, my first interest is in getting the GTK stuff to show up and
that is controller by HAVE_PCAP_REMOTE ..
--
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)