On 3 okt 2010, at 20:18, Guy Harris wrote:

> On Oct 3, 2010, at 5:08 AM, Sake Blok wrote:
> 
>> I was able to make things work for "pcap_open_dead", but when trying to do 
>> the same for "bpf_image", I still run into problems at the linking stage 
>> where "bpf_image" can not be found. I checked the WinPcap header files and 
>> bpf_image is there.
> 
> ...and, at least for WinPcap 4.1.1, bpf_image is in the .def file.

Which .def file are you referring too?

> Where is it failing?

It was failing in both "capture_filter_compile_cb" and "dumpcap.c", the only 
places where bpf_image is used. As long as HAVE_BPF_IMAGE is not defined, all 
is fine (except, the compile BPF button is not available and neither is dumpcap 
-d). But if I "add support for" bpf_image in the same way as I added support 
for pcap_open_dead, the linker complains that bpf_image can not be found.

>  The buildbot seems to be doing OK.

That's because I did not want to break it yet another time, I have been 
pestering everyone enough this weekend ;-)
So when it did not work on my WinXP dev VM, I decided to ask here first!

>> Hmmm... do we need to define "HAVE_PCAP_COMPILE_NOPCAP" and check for it? Or 
>> can we safely assume it's there in all supported platforms?
> 
> If we don't support any platforms that use libpcap before libpcap 0.5, we can 
> safely assume it's there, although I think there might be some older versions 
> of NetBSD where pcap_compile_nopcap() took an additional argument (a char * 
> pointing to a buffer into which it put an error message if it failed - 
> pcap_compile_nopcap() as implemented in tcpdump.org libpcap can't give you an 
> error message for the failure, but pcap_open_dead()/pcap_compile() can).
> 
> libpcap 0.4 had neither pcap_open_dead() nor pcap_compile_nopcap() - you 
> *had* to have a live capture device or a savefile open in order to compile a 
> filter into BPF code.

So, that sounds to me like we should just use these functions without adding 
complexity by using "HAVE_PCAP_COMPILE_NOPCAP" until someone knocks at our door 
telling us that (s)he has a problem with these functions on their platform.

Cheers,


Sake

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Reply via email to