Re: pcap_read_linux_mmap() not returning packets on time

[Cristian Morales Vega <cristian () samknows com>]

The simple version is that I am seeing poll repeatedly returning
POLLIN but when pcap checks the mmaped memory it finds TP_STATUS_USER
is not set.

> From what I can see the only thing poll
(net/packet/af_packet.c:net/packet/af_packet.c) does is check if
TP_STATUS_USER is set. So, could it be that pcap is not looking in the
correct place? Even in this case I can't explain why after a while all
the packets appear to pcap.

ps. it's using TPACKET_V2


On 11 September 2013 11:25, Cristian Morales Vega <cristian () samknows com> wrote:
> I am having a problem using libpcap in my program and I would like a
> bit of guidance before I try to understand how Linux PACKET_MMAP
> works.
>
> Using an unpatched libpcap 1.4.0 (and a OpenWRT patched  1.1.1) I find
> this call:
>
> pcap_dispatch(pcap_descr, -1, placeholder, NULL);
>
> after a blocking, successful, read() sometimes doesn't return any packet.
>
> Adding a few printf() to libpcap I found that in
> pcap_read_linux-mmap() sometimes,
> a) The first pcap_get_ring_frame() returns NULL
> b) poll() immediately returns 1 (pcap_descr is non blocking)
> c) The pcap_get_ring_frame() in the while returns NULL in the first iteration
>
> Since poll() says there is a packet, shouldn't pcap_get_ring_frame
> return it? I mean, shouldn't be 100% guaranteed?
>
> The behaviour I am seeing is that for some periods all pcap_dispatch()
> calls return 1 without even calling poll(). But for some other
> periods, that can last *minutes* hundreds of pcap_dispatch() calls
> return 0 just to then get all these missing packets in a single
> pcap_dispatch() call.
>
>
> The program is running in one of these things:
> http://wiki.openwrt.org/toh/tp-link/tl-wdr3600. I don't discard the
> possibility of a problem in the network driver. But what kind of
> problem would make read() and poll() see the packets, but not
> pcap_get_ring_frame()?
>
> There is a bug here (probably not in libpcap) or is all this expected?
>
>
> Thanks.
>
> --
> Cristian Morales Vega
>
> Email cristian () samknows com
> Office +44 (0) 20 3111 4330
> Web:  www.samknows.com
>
>
> This email is sent for and on behalf of SamKnows Limited.
>
> This email and any attachments are confidential, legally privileged
> and protected by copyright. If you are not the intended recipient
> dissemination or copying of this email is prohibited. If you have
> received this in error, please notify the sender by replying by email
> and then delete the email completely from your system.
>
> SamKnows Limited, Registered Number: 06510477, Registered Office: Hill
> House, 1 Little New Street, London, EC4A 3TR. Registered in England
> and Wales. Trade Mark 2507103



-- 
Cristian Morales Vega

Email cristian () samknows com
Office +44 (0) 20 3111 4330
Web:  www.samknows.com


This email is sent for and on behalf of SamKnows Limited.

This email and any attachments are confidential, legally privileged
and protected by copyright. If you are not the intended recipient
dissemination or copying of this email is prohibited. If you have
received this in error, please notify the sender by replying by email
and then delete the email completely from your system.

SamKnows Limited, Registered Number: 06510477, Registered Office: Hill
House, 1 Little New Street, London, EC4A 3TR. Registered in England
and Wales. Trade Mark 2507103
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers