On 3/11/2010 10:23 AM, Selçuk Cevher wrote:
> Hi All,
>
> As far as I know, libpcap is capable of packaging certain amount of binary
> data in the form of an Ethernet frame.
>
> I wonder if libpcap is capable of combining several Ethernet frames
> constructed by itself or obtained from a live ca
Jim Lloyd wrote:
> Over the last couple months we have developed and deployed into a production
> environment an application using libpcap, where we sniff upwards of 350Mbps
> of HTTP traffic arriving via a SPAN. On the whole I am extremely pleased
> with libpcap in terms of both the ease of implem
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
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
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
Guy Harris wrote:
>
> On Aug 31, 2009, at 2:36 PM, Dustin Spicuzza wrote:
>
>> So... I've changed my patch to populate ps_ifdrop instead, and it should
>> be good to go, without screwing with current applications.
>
> Checked in.
>
Thanks! Except I foun
Guy Harris wrote:
> I think that
>
>> +handle->md.stat.ps_drop += (handle->md.proc_dropped -
>> if_dropped);
>
> and
>
>> +stats->ps_drop = handle->md.stat.ps_drop;
>
> are wrong, because ps_drop is supposed to reflect the number of packets
> dropped by the packet capture mechanism
Stephen Donnelly wrote:
> Dustin Spicuzza wrote:
>
>>> So after reading the libpcap and kernel source, I see that this is
>>> actually how its supposed to work. But it *seems* like it would be quite
>>> nice if we could grab the interface driver drop statistics as
Dustin Spicuzza wrote:
> Dustin Spicuzza wrote:
>> Hey,
>>
>> I've been trying to determine the performance of my application (ie,
>> when does it start dropping packets). I am using the current version of
>> libpcap in git, with Ubuntu 9.04 server (kernel 2.
Dustin Spicuzza wrote:
> Hey,
>
> I've been trying to determine the performance of my application (ie,
> when does it start dropping packets). I am using the current version of
> libpcap in git, with Ubuntu 9.04 server (kernel 2.6.28-15-server). I am
> using the new pcap AP
Hey,
I've been trying to determine the performance of my application (ie,
when does it start dropping packets). I am using the current version of
libpcap in git, with Ubuntu 9.04 server (kernel 2.6.28-15-server). I am
using the new pcap API calls to set the ring buffer to something like
2GB, and I
In git, pcap_fopen_offline (and consequently, any of the other savefile
opens) doesn't work with pcap_next because the oneshot_op is not set to
anything.
One can remedy this by using pcap_create_common to create the pcap_t
instead of doing it manually. Of course, the 'source' isn't set
properly...
Dustin Spicuzza wrote:
> On linux using the latest GIT:
>
> If you use pcap_create followed by pcap_activate when an interface
> doesn't actually exist (ie, PCAP_ERROR_IFACE_NOT_UP is returned), then
> pcap_geterr will return a blank value.
>
> I noticed that the docu
On linux using the latest GIT:
If you use pcap_create followed by pcap_activate when an interface
doesn't actually exist (ie, PCAP_ERROR_IFACE_NOT_UP is returned), then
pcap_geterr will return a blank value.
I noticed that the documentation does mention all the various error
codes that could be
Guy Harris wrote:
>
> On Jul 15, 2009, at 12:40 PM, Dustin Spicuzza wrote:
>
>> Found this bug while trying to add the buffer statistics API. git
>> formatted patch attached:
>>
>> - Fixed bug where create_ring would fail for particular snaplen and
>> buf
Guy Harris wrote:
>
> On Jul 14, 2009, at 9:05 AM, Dustin Spicuzza wrote:
>
>> I'd like to get information on how much of the mmap'ed ring buffer is
>> being used so that I can deal with dropped packets more effectively. I
>> was going to add a patch for t
away
From 219c99d5830c79b336f63dcc10debab37a41ce1b Mon Sep 17 00:00:00 2001
From: Dustin Spicuzza
Date: Wed, 15 Jul 2009 14:58:16 -0400
Subject: [PATCH] Bugfix/improvement for linux mmap ring buffer
- Fixed bug where create_ring would fail for particular snaplen and buffer size
combinations
Guy Harris wrote:
>
> On Jul 14, 2009, at 9:05 AM, Dustin Spicuzza wrote:
>
>> I'd like to get information on how much of the mmap'ed ring buffer is
>> being used so that I can deal with dropped packets more effectively. I
>> was going to add a patch for t
Hey,
I'd like to get information on how much of the mmap'ed ring buffer is
being used so that I can deal with dropped packets more effectively. I
was going to add a patch for this, but its not clear to me the best way
to expose the information. I'm tempted to just add an additional
call/struct fo
January 15, 2004, apparently.
And yet, they're linked to on the homepage. Might be useful to update
them. :)
Dustin
--
Innovation is just a problem away
signature.asc
Description: OpenPGP digital signature
Dustin Spicuzza wrote:
> Dustin Spicuzza wrote:
>
> And it will rotate the logs around every half hour storing only headers.
> Of course the only part I did was add the -s headers option..
>
Oh, on a related note, if you use the rotate functionality and you tell
it to drop priv
Dustin Spicuzza wrote:
> Guy Harris wrote:
>> On Dec 17, 2008, at 2:30 PM, Dustin Spicuzza wrote:
>>
>>> Speaking of which, is there something in tcpdump that can figure out how
>>> long the header is... I see that the printers figure out this
>>> informat
Guy Harris wrote:
>
> On Dec 17, 2008, at 2:30 PM, Dustin Spicuzza wrote:
>
>> Speaking of which, is there something in tcpdump that can figure out how
>> long the header is... I see that the printers figure out this
>> information, but its not done separately as far
Guy Harris wrote:
>
> On Dec 17, 2008, at 12:18 PM, Matthew Luckie wrote:
>
>> could -s become a parameter that takes words as well as numbers, and
>> have the compiler return the appropriate number of bytes in each
>> case?. so -s udphdr -s tcphdr would return 14 + 20 + 8 for UDP
>> packets on
Guy Harris wrote:
>
> On Dec 17, 2008, at 12:43 PM, Dustin Spicuzza wrote:
>
>> ... as long as you trust that the header
>> values are ok (making sure that they stay in the bounds of the actual
>> packet size).
>
> Don't do that. Check against the inco
Matthew Luckie wrote:
> Guy Harris wrote:
>
> could -s become a parameter that takes words as well as numbers, and
> have the compiler return the appropriate number of bytes in each case?.
> so -s udphdr -s tcphdr would return 14 + 20 + 8 for UDP packets on
> ethernet, and tcphdr would return 14
Hey,
Is there currently a way to save protocol headers (and by this, I mean
ARP/IP/TCP/UDP/ICMP headers) to a file *without* the remaining payload?
If not, I could be motivated to write a patch to do this (it doesn't
seem like it would be that hard?) if someone just points me to the right
area
27 matches
Mail list logo
