Salih
the #ifndef is there because it has to be there. In fact if you remove it your 
machine locks. Live it like that please

Luca

On Jun 27, 2011, at 3:28 PM, <[email protected]> 
<[email protected]> wrote:

> Luca,
> in pcap-linux.c:5000, there’s a code block that seems to drain packets 
> currently in the queue. But it requires that HAVE_PF_RING be not defined. 
> Isn’t it something similar to this one what we need, to drain packets from 
> the ring.
> If I try to run this block by commenting #ifndef/#endif sytems locks up and I 
> get a “soft lockup” error. Why can’t we use this when HAVE_PF_RING is defined?
> Regards
> From: Luca Deri
> Sent: Monday, June 27, 2011 3:17 PM
> To: [email protected]
> Subject: Re: [Ntop-dev] pf_ring nonfiltered packets
> Salih please go ahead and modify the pcap-over-pf_ring library. The trick is 
> to find a place in the pcap library where to call pfring_enable_xxx so that 
> it is called after the filter has been set. Done that please mail me the code 
> patch
> Luca
> On Jun 27, 2011, at 1:20 PM, <[email protected]> 
> <[email protected]> wrote:
> 
>> Hi,
>> tried rev4693 and still some packets are received before filter gets control
>> Regards,
>> Salih
>> Salih
>> tcpdump works via pcap and thus there's an extra layer to take care. I am 
>> currently modifying the library to prevent this behaviour. In fact in pfring 
>> as soon as you open a socket packets are coming, then tcpdump sets a filter 
>> and packets are filtered. However packets in queue are unfiltered. Can you 
>> please try the code in SVN and see if the behaviour changes with the fixes 
>> we did yesterday?
>> 
>> Thanks Luca 
>> 
>> On Jun 27, 2011, at 11:57 AM, <[email protected]> wrote:
>> 
>> > Hi,
>> > I am trying to use pfring on my system with very high traffic load (around 
>> > 600kpps). When I open tcpdump with some filters, first few packets 
>> > captured do not match the filter I set, but after a short while, the 
>> > filter seems working as intended. Its like it takes a while to apply the 
>> > filter, but packets captured during that time are delivered to upper 
>> > layers nonetheless.
>> > Anybody else noticed a similar issue??
>> > Salih
>> > _______________________________________________
>> > Ntop-dev mailing list
>> > [email protected]
>> > http://listgateway.unipi.it/mailman/listinfo/ntop-dev
>> _______________________________________________
>> Ntop-dev mailing list
>> [email protected]
>> http://listgateway.unipi.it/mailman/listinfo/ntop-dev
> ---
> If you can not measure it, you can not improve it - Lord Kelvin
> 
> _______________________________________________
> Ntop-dev mailing list
> [email protected]
> http://listgateway.unipi.it/mailman/listinfo/ntop-dev
> _______________________________________________
> Ntop-dev mailing list
> [email protected]
> http://listgateway.unipi.it/mailman/listinfo/ntop-dev

---
If you can not measure it, you can not improve it - Lord Kelvin

_______________________________________________
Ntop-dev mailing list
[email protected]
http://listgateway.unipi.it/mailman/listinfo/ntop-dev

Reply via email to