[Winpcap-users] Re: reducing dropped packets

[David Chang]

Guy,

This is really good info.

In Linux, I was able to increase the socket receive buffer using:

sysctl -w net.core.rmem_max=4194304
sysctl -w net.core.rmem_default=4194304

And the number of dropped packets went to zero.  Just like you said, I had 
to restart the capture process to take advantage of these settings.

I'm going to figure out what I need to do for Solaris.

Thanks,

DC

----- Original Message ----- 
From: "Guy Harris" <guy at alum.mit.edu>
To: <winpcap-users at winpcap.org>
Sent: Thursday, October 19, 2006 12:06 AM
Subject: Re: [Winpcap-users] Re: reducing dropped packets


> David Chang wrote:
>> When you say 'the buffer size needs to specified at open time.'  When is 
>> the open time ? (i.e.  pcap_open_live)
>
> Yes.  You can't change the buffer size (it's done with the BIOCSBLEN 
> ioctl) once the BPF device has been bound to a network interface, and the 
> open routine binds the BPF device to the interface you're opening (as 
> that's part of what an open is).
>
>> Is it easy to change the libpcap source to increase the buffer?
>
> If you want to wire in a particular bigger size, yes.  The current version 
> tries to set it to 32768, and if that fails with ENOBUFS (meaning "that's 
> too big", it tries again with 16384, and keeps shrinking).
>
> It will not, however, set it to a smaller value than the default.
>
> You could, on most BSDs (including OS X), try setting debug.bpf_bufsize to 
> a larger value with the sysctl command.  Note, however, that
>
> 1) the buffer is wired-down kernel memory, so it consumes a 
> relatively-scarce kernel resource
>
> and
>
> 2) the default is used for *all* BPF where the application doesn't 
> explicitly change it, so this might affect, for example, system daemons
>
> so such a daemon could end up chewing up a significant amount of a kernel 
> resource.  This is not a hypothetical example - I once made my Mac 
> incapable of re-DHCPing for its network parameters after waking up by 
> boosting debug.bpf_bufsize, as the DHCP client uses BPF, it's run after 
> waking up from a sleep (at least on a notebook, it needs to do that 
> because it might be waking up on a completely different network), and, in 
> this case, I was either running some libpcap-based application or some 
> other daemon also had a BPF device open, as the BPF open by the DHCP 
> client failed.
>
> On other platforms, you'd make some other changes.  On Linux, I *think* 
> the equivalent would be to crank up the socket receive buffer size on the 
> PF_PACKET socket.  Check out, I think, the bufmod man page on Solaris to 
> determine the equivalent there; I think the man page for Digital/Tru64 
> UNIX would be the packetfilter man page.  On other OSes using sockets, 
> it'd probably again be the socket receive buffer size.
> _______________________________________________
> Winpcap-users mailing list
> Winpcap-users at winpcap.org
> https://www.winpcap.org/mailman/listinfo/winpcap-users
>