Re: Libpcap on VMWare

[Vikram Roopchand <vikram.roopchand () j-interop org>]

> > If so , how do we configure it from outside so
> > that we can increase it's size also ?
>
> ...it's irrelevant to the problem you're having.  The problem is probably that 
libpcap, and your program,
> aren't reading packets fast enough, so, given that the socket buffer has a 
finite size, that buffer can
> eventually fill up, at which point any more packets that arrive will be 
dropped.  Making the socket buffer
> bigger will help there *IF* the program+libpcap is capable, on average, of 
reading and processing
> packets as fast as, or faster than, they arrive - the buffer only helps if the 
inability to process packets
> at full speed is temporary (program gets temporarily slowed down by, for 
example, having to write the
> packets to a file, or a short burst of packets arrives too fast) and the 
program can later catch up.
> The buffer in libpcap only has to be big enough for the chunk of packets 
libpcap reads - and, in versions of
> libpcap prior to 1.0.0, it does a recvfrom() on a PF_PACKET socket, and gets 
one packet at a time, so the
> buffer in libpcap only needs to be big enough for one packet.

However, the load on our test setup is not that high. We have increased the 
socket buffer size to 128M. To really stretch , it would be 100 packets per 
second with average size being no more than 1500 bytes. We still get drops. 
Another thing we use pcap_dispatch (via jnetpcap) with number of packets to 
capture set to 1000 and our tests return immediately from the handler functions 
without performing any copy or processing related operations. According to Mark 
jnetpcap does not perform a copy either. I am not sure where the issue lies , 
perhaps it's VMWar e drivers , perhaps not. But I doubt we (libpcap + jnetpcap + 
testcode) are not reading the data fast enough :( ...

thanks again,
best regards,
Vikram

-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.