Mailing List Archive

PF_RING packets partial capture/transmission
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?
Re: PF_RING packets partial capture/transmission [ In reply to ]
Hrju,
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@listgateway.unipi.it
> 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@listgateway.unipi.it
http://listgateway.unipi.it/mailman/listinfo/ntop-dev
Re: PF_RING packets partial capture/transmission [ In reply to ]
Hi Luca,
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?

Thanks


On Tue, May 1, 2012 at 8:56 PM, Luca Deri <deri@ntop.org> wrote:

> Hrju,
> 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@listgateway.unipi.it
> > 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@listgateway.unipi.it
> http://listgateway.unipi.it/mailman/listinfo/ntop-dev
>