> I solved the problem by adding after the "pcap_compile" and > "pcap_setfilter" functions in my callback routine a "pcap_loop" in order to > provide again to PCAP the callback address function.
One thing we *don't* support is calling "pcap_loop()" in a callback function called from "pcap_loop()".... > I don' understand why the callback address was not set anymore > properly. The callback address has nothing to do with crashing in "bpf_filter()"; how do you know that the callback address wasn't set - especially given that it's not "set" in the sense of being stored in the "pcap_t"; it's passed as an argument from "pcap_loop()" to "pcap_offline_read()" or "pcap_read()", but not stored anywhere. > Is it necessary to invoke the pcap_loop function after changing the > filter expression ? No. > Could you also tell me if PCAP may loose some packets during the filter > expression change ? If you're changing the expression filter on a savefile, no. If you're changing the filter expression on a live capture, yes, and we cannot arrange that they not be lost - on some OSes, if you set the filter in the kernel, the kernel filtering code throws away unread packets (to get rid of packets that would've passed the old filter but not the new filter). On platforms where filter is *not* done in the kernel, such as Solaris, you shouldn't lose packets, however. - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe
