From: Benjamin Poirier
Date: Mon, 06 Jul 2009 14:04:32 -0400
> move the point where the support routine for packet capture is called to
> better reflect what is transmitted on the wire when GSO is active.
>
> At the moment, packet capture (a la tcpdump) on the transmission side happens
> before
On Jul 6, 2009, at 11:08 AM, Dragos Ilie wrote:
My application is not setting the timeout. This corresponds to the
case
where p->md.timeout == 0. The function pcap_setnonblock_mmap first
checks the nonblock flag and if it is set *and* if p->md.timeout > 0
it
maps the value to p->md.timeou
move the point where the support routine for packet capture is called to
better reflect what is transmitted on the wire when GSO is active.
At the moment, packet capture (a la tcpdump) on the transmission side happens
before GSO takes place (if it does). Therefore, even if a packet gets
segmented
Guy Harris wrote:
>
> On Jul 6, 2009, at 9:39 AM, Dragos Ilie wrote:
>
>> I traced the issue to pcap-linux.c:pcap_read_linux_mmap(), which is the
>> read handler selected when HAVE_PACKET_RING is defined. The handler
>> calls poll() with a negative value, which means an infinite timeout.
>> This oc
On Jul 6, 2009, at 9:39 AM, Dragos Ilie wrote:
I traced the issue to pcap-linux.c:pcap_read_linux_mmap(), which is
the
read handler selected when HAVE_PACKET_RING is defined. The handler
calls poll() with a negative value, which means an infinite timeout.
This occurs when the libpcap variable
I have an application that uses libpcap in non-blocking mode
(pcap_setnonblock). The application reads one packet at a time using
pcap_dispatch(). My understanding is that pcap_dispatch should return
immediately when no packets are available. However, this is not
happening. Instead, pcap_dispatch(
January 15, 2004, apparently.
And yet, they're linked to on the homepage. Might be useful to update
them. :)
Dustin
--
Innovation is just a problem away
signature.asc
Description: OpenPGP digital signature
