Ah that makes sense. Thanks for the clarification.<br><div class="gmail_quote"><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">





<div bgcolor="#ffffff">
<div><font size="2">If you set the timeout to 0 (infinite timeout), mintocopy is 
the factor affecting the reception.</font></div></div></blockquote><div>&nbsp;</div><div>Where is mintocopy defined? <br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#ffffff"><div></div>
<div><font size="2">pcap_next_ex (or any other WinPcap receive function) will 
return</font></div>
<div><font size="2">- after the timeout (unless you used 0)</font></div>
<div><font size="2">- when at least mintocopy bytes are stored in the kernel 
buffer</font></div>
<div><font size="2"></font>&nbsp;</div>
<div><font size="2">(whatever happens first).</font></div>
<div><font size="2"></font>&nbsp;</div>
<div><font size="2">It&#39;s not a bug in WinPcap, this is by design. Why are you 
using an infinite timeout?</font></div>
<div></div></div></blockquote><div><br>Is that the intended usage, to use a timeout? I really do not need to have a timeout; I want a packet when it arrives. But if the only way to circumvent mintocopy is to have a timeout, then I don&#39;t mind it. Then I suppose pcap_next_ex() would be more useful than pcap_next() since its return code indicates a timeout...<br>
<br>Is there a way to change the size of mintocopy? I am guessing no, since that&#39;s kernel level code.<br><br>Cheers,<br>Oliver<br></div></div>