Read the code a little more carefully and you will find that it's in there, but not easy to read. grep for pcap_compile() you'll notice that only in the main code is it applied via pcap_setfilter(). The plugins pcap_compile is creating a filter program to be used by pbuf.c to figure out which plugins need to see the packet - grep for myGlobals.flowsList.
However, that's irrelevant... Using a bpf cause libpcap to strips out the packets - meaning ntop never sees them. You don't want to do that. If you had applied the correct (AND) filter, you would be here saying it's not seeing ANY traffic. What you want is to record only the local hosts - which is the -g | --track-local-hosts switch. If that's not working, then that's a completely separate issue. Please file a full Problem Report and include a short tcpdump packet capture (something like tcpdump -c25 ip, so we can see there really is traffic and what it looks like. -----Burton -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Devdas Bhagat Sent: Saturday, August 09, 2003 9:38 AM To: [EMAIL PROTECTED] Subject: Re: [Ntop] ntop BPF issues. On 09/08/03 08:29 -0500, Burton M. Strauss III wrote: > What do you mean 'doesn't work'? Is it being rejected? Or just doesn't > seem to function? You may need --trace-level 5 to see all of the filter > related log messages. It isn't functioning. I peeked in the source and bpfFilter seems to be enabled only in the plugins. > Syntactically, that seems correct, but useless. If you're monitoring a LAN, > pretty much all the traffic you see WILL have either it's Source or > Destination as part of the local network. If you're trying to limit > yourself to LOCAL traffic only, then use AND not OR. What I am trying to do is not record the other end of the connection (ie, record only the local side of the connection). Sometimes ntop is being overwhelmed by the sheer volume of data generated. Say I have a connection from 192.168.1.2 to 66.14.13.254 (both hypothetical numbers). I want to record the traffic coming from and going to 192.168.1.2 without having to make a corresponding table entry for 66.14.13.254. This should theoretically be possible with --track-local-hosts and the appropriate subnet, but that is simply refusing to record traffic currently. I'll look into why it is behaving like that, I guess. Devdas Bhagat _______________________________________________ Ntop mailing list [EMAIL PROTECTED] http://listgateway.unipi.it/mailman/listinfo/ntop _______________________________________________ Ntop mailing list [EMAIL PROTECTED] http://listgateway.unipi.it/mailman/listinfo/ntop
