On Jan 12, 2010, at 5:59 PM, Mark Bednarczyk wrote:
> No drops on NON-vmware platforms.
So at least some of the problem could involve a code path difference on VMware,
e.g. either the VMware code itself or whatever code in the guest OS receives
packets from VMware. Is VMware simulating a hard
> > 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,
Guy Harris wrote:
> On Jan 12, 2010, at 7:05 PM, Dustin Spicuzza wrote:
>
>> Yes, that was what I meant. We never tried -1. We're running single
>> threaded with a select loop for pcap on two devices and some network
>> communications, so we figured on the off chance that -1 would never
>> return
What if I send a mail message with no newline at the end?
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
On Jan 12, 2010, at 7:05 PM, Dustin Spicuzza wrote:
> Yes, that was what I meant. We never tried -1. We're running single
> threaded with a select loop for pcap on two devices and some network
> communications, so we figured on the off chance that -1 would never
> return (which I'm sure it would)
Guy Harris wrote:
> On Jan 12, 2010, at 1:42 PM, Dustin Spicuzza wrote:
>
>> I haven't used the mmap'ed ring buffer on VMWare, but we used a 2GB
>> buffer to allow us to read/process 500Mbps off two interfaces with zero
>> packet loss over the period of a few days.
>
> 32-bit or 64-bit kernel, and
Hi,
I have been working with Vikram on this issue and let me comment as well if
I may. The tests we are running are both under jNetPcap and under a native C
application without jNetPcap involved at all. My jNetPcap based tests don't
actually interact with java at all during capture. Java part is u
On Jan 12, 2010, at 1:42 PM, Dustin Spicuzza wrote:
> AFAIK, using environment variables to change the configuration of an
> internal ring buffer is only implemented in Phil Wood's patched libpcap
> that you mentioned at http://public.lanl.gov/cpw/.
Yes, that's the case.
> At some point, someon
On Jan 12, 2010, at 1:38 AM, Vikram Roopchand wrote:
>This is similar in nature to
> http://article.gmane.org/gmane.network.tcpdump.devel/4256 posting (which is
> unfortunately unsolved). We are using jnetpcap which is a wrapper over
> libpcap. Mark Bednarczyk posted the original
From: Christian Bell
Can be squashed with previous patch, if previous is acceptable.
---
configure.in |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/configure.in b/configure.in
index 4a7c629..46f45c7 100644
--- a/configure.in
+++ b/configure.in
@@ -1082,7 +1082,11
Vikram Roopchand wrote:
>
> May we also know what is this ring buffer people keep talking about ? Does
> libpcap standard distro have a ring buffer (related to the question above) ?
> And can PCAP_MEMORY or PCAP_FRAMES environment variable help increase it (as
> in the link above and here http://se
> "sthaug" == sthaug writes:
>> Well, it gets in the way of all types of things, for example:
>>
>> tcpdump-v -i foo.cap | egrep pattern | wc -l
>>
>> I think the behaviour should be the reverse of the -g in Mac OS X
>> and that is it should be necessary to use some
I forgot to mention, we do set a filter (Host IP and TCP Port) on libpcap.
thanks again,
best regards,
Vikram
On Tue, Jan 12, 2010 at 3:08 PM, Vikram Roopchand <
vikram.roopch...@j-interop.org> wrote:
> Hello There,
> This is similar in nature to
> http://article.gmane.org/gmane
Hello There,
This is similar in nature to
http://article.gmane.org/gmane.network.tcpdump.devel/4256 posting (which is
unfortunately unsolved). We are using jnetpcap which is a wrapper over
libpcap. Mark Bednarczyk posted the original query (4256).
-
14 matches
Mail list logo
