[Winpcap-users] Re: reducing dropped packets
dchang at fsautomation.com
Thu Oct 19 17:03:00 GMT 2006
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.
----- 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
> 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
More information about the Winpcap-users