On Jan 15, 2012, at 6:44 PM, Gianluca Varenni wrote:
> Hi all.
>
> It looks like there is a bug in handling a snaplen of 1500 on linux (with
> mmap on). If I set a snaplen of 1500 and receive packets > 1500 (e.g. 1514),
> libpcap returns only 1498 as caplen, and not 1500.
>
> Libpcap latest o
Hi all.
It looks like there is a bug in handling a snaplen of 1500 on linux (with mmap
on). If I set a snaplen of 1500 and receive packets > 1500 (e.g. 1514), libpcap
returns only 1498 as caplen, and not 1500.
Libpcap latest on git (1.3.0-PRE-GIT_2012_01_15)
Linux RHEL6, kernel 2.6.32-131.21.1.
On Jan 15, 2012, at 3:11 PM, Fernando Gont wrote:
> For my current app, it's probably just "annoying" (although no big
> deal). However, I was mostly concern about performance problems in other
> applications. Put another way, if there's nothing that an app can do
> without a packet being read, t
Hi, Guy,
On 01/15/2012 07:28 PM, Guy Harris wrote:
>> The reason is that if I pcap_open_live() with a "to_ms" of 0, in
>> some systems pcap_next_ex() will remain blocked even if a packet is
>> received (i.e., it will wait for *many* packets).
>
> At least on systems with BPF, it'll block until th
On Jan 15, 2012, at 9:36 AM, Fernando Gont wrote:
> I'd like a call to pcap_next_ex() to block, waiting for a single packet,
> with no timeout.
>
> So far, the only portable way to do it I've found is to select() on the
> underlying descriptor.
>
> The reason is that if I pcap_open_live() with
Folks,
I'd like a call to pcap_next_ex() to block, waiting for a single packet,
with no timeout.
So far, the only portable way to do it I've found is to select() on the
underlying descriptor.
The reason is that if I pcap_open_live() with a "to_ms" of 0, in some
systems pcap_next_ex() will remain
