dljavsjakojhujni at gmail
May 1, 2012, 3:41 PM
Post #3 of 3
Re: PF_RING packets partial capture/transmission
[In reply to]
Thanks for the quick answer.
I'm using the source from the libpcap official git repository. From your
answer I can conclude that the libpcap support for memory-mapped capture is
not necessary based on you infrastructure. If so, sorry for bothering you.
Anyway, could you provide some common directions for the investigation? MTU
size? TSO issues?
On Tue, May 1, 2012 at 8:56 PM, Luca Deri <deri [at] ntop> wrote:
> we do not support PF_RING over libpcap 1.2: who did the port? I think you
> should contact the developer and send us the code so that we can integrate
> it and see what the problem could be.
> Regards Luca
> On May 1, 2012, at 6:09 PM, Hrju Blja wrote:
> > Hi,
> > I develop a Linux sniffer application , which uses libpcap 1.2.0
> library, which, in turn, uses PF_RING infrastructure to retrieve captured
> packets. The problem is that on some Suse 2.6 kernel machine, which is
> pretty much usual, SOMETIMES SOME packets are captured partially, i.e.
> tpacket_hdr structure tp_snaplen value is less then tp_len value. I see
> this right after that libpcap code calls RING_GET_FRAME on pcap_t handle,
> so my assumption is that libpcap in not "guilt" here.
> > I'm really sorry for the "SOMETIMES", but I've failed to isolate a
> problem, it may happen on single connection for a number of packets, while
> the rest are OK.
> > So before I drill down to PF_RING and kernel debugging, may some of your
> guys have an idea why that weird stuff may happen?
> > _______________________________________________
> > Ntop-dev mailing list
> > Ntop-dev [at] listgateway
> > http://listgateway.unipi.it/mailman/listinfo/ntop-dev
> We can't solve problems by using the same kind of thinking we used when we
> created them - Albert Einstein
> Ntop-dev mailing list
> Ntop-dev [at] listgateway