headers
rixed | 1 Jun 2011 10:15
Gravatar

Re: [libpcap][patch] appending to a capture

In defense of the OP, I must say I like the idea of a
pcap_dump_append().

Your arguments against it are a lot more valid with regard to the
tcpdump tool, for which an "--append" parameter seams dubious, than for
the libpcap itself which can be used by many different programs for many
different purposes, and editcap may not be an option here.

> That said, I can also imagine people using this function
> and running into huge performance problems.

I fail to imagine any performance problems. Any examples please?
Permalink | Reply | 0 comments |
headers
mold2010 | 1 Jun 2011 14:58
Favicon

Re: Re: [tcpdump-workers] libpcap1.1.1 truncates UDP payload, ring buffer problem?


I tried libpcap1.1.1 release libpcap_1_1rel0 from https://github.com/mcr/libpcap. But found the same
issue. Where can I get the 1.2 branch? Is it git hub: libpcap?
I do not know if it is a Suse problem. I have a plan to try Redhat ES5.4 to see if there is still this problem.



在2011-06-01，guy发给您的邮件内容如下
------------------------------------------------------------------------------

From: "Guy Harris" 
To: tcpdump-workers <at> lists.tcpdump.org
Date: 2011-06-01 00:54:17
Subject: 

On May 31, 2011, at 7:36 AM, mold2010 wrote:



> I have a problem about libpcap ring buffer. The problem is the packets captured by libpcap1.1.1 which uses
ring 

> buffer are truncated.



Does this happen with the current top-of-tree libpcap (regardless of the version of tcpdump with which it
was linked; tcpdump and libpcap are released together, but tcpdump is supposed to be able to run with
versions of libpcap other than the one released with it)?  The trunk and the 1.2 branch have some ring buffer
changes to fix some problems such as that.-
(Continue reading)

Permalink | Reply | 1 comment |
headers
Mark Johnston | 1 Jun 2011 17:10
Picon

Re: [libpcap][patch] appending to a capture

Hi Darren,

On Tue, May 31, 2011 at 03:53:22PM -0700, Darren Reed wrote:
> Hi Mark,
> 
> I must admit that I don't see the point of this patch.
> 
> A pcap data file, with packets in it, is something that
> I would create using tcpdump over a specific period
> of time. The data file is thus associated with a very
> specific set of actions. To then append data to that
> file without that data being associated with the
> original action seems wrong.

In my tree at work, the function in used in a program quite similar
to tcpflow. I agree that it doesn't make sense to cat the output of
multiple tcpdump sessions into a single capture file, but it depends on
what I want to do with the recorded packets... in my case they're used
by another program to replay captured flows, so the context in which
they were originally captured doesn't really matter.

> 
> That said, I can also imagine people using this function
> and running into huge performance problems.

I don't see how that is. The function essentially does the following:

- Check if we're writing to stdout. If so, write a header and return.
- Open the file, read the header and make sure it matches the one passed
  into the function.
(Continue reading)

Permalink | Reply | 12 comments |
headers
Gerald Combs | 1 Jun 2011 18:24
Favicon
Gravatar

Re: [libpcap][patch] appending to a capture

On 6/1/11 8:10 AM, Mark Johnston wrote:
> Hi Darren,
> 
> On Tue, May 31, 2011 at 03:53:22PM -0700, Darren Reed wrote:
>
>> You might be better off spending some time working
>> on additions to editcap that include concatenating
>> two or more pcap files.
> 
> Shouldn't a function that manipulates capture files go into libpcap? I'm
> not trying to solve a problem I'm having at the moment; rather, this
> function has been in our tree for a long time, and I'd like to
> contribute it upstream based on some interest that I saw. I'm happy to
> modify it if that's what I need to do, but I think this functionality
> should be in a library, not in a program.

N.B. this functionality shouldn't be added to editcap either. It's
already present in mergecap.

--

-- 
Join us for Sharkfest ’11! · Wireshark® Developer and User Conference
Stanford University, June 13-16 · http://sharkfest.wireshark.org
Permalink | Reply | 7 comments |
headers
Michael Richardson | 1 Jun 2011 20:13
Picon
Gravatar

Re: [libpcap][patch] appending to a capture


Yeah, I'd rather that we have a good set of pcap manipulation tools.
Maybe we just need better pointers to mergecap and editcap?

--

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr <at> sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.
Permalink | Reply | 5 comments |
headers
Sam Roberts | 1 Jun 2011 20:48
Picon
Gravatar

Re: [libpcap][patch] appending to a capture

On Wed, Jun 1, 2011 at 11:13 AM, Michael Richardson <mcr <at> sandelman.ca> wrote:
> Yeah, I'd rather that we have a good set of pcap manipulation tools.
> Maybe we just need better pointers to mergecap and editcap?

I don't see extensions to libpcap and a good set of tools as an either/or thing.

I'd be pretty happy to see the capabilities of tools such as mergecap,
editcap, and tcpslice presented as C callable APIs.

Its possible to shell out to do pcap manipulations, but its often more
useful to bind C APIs into your working language, allowing you to
combine effects in interesting ways that might not be forseen by the
command line tools.

If not in libpcap, maybe libcaptool?

Cheers,
Sam
Permalink | Reply | 4 comments |
headers
Michael Richardson | 1 Jun 2011 21:43
Picon
Gravatar

Re: [libpcap][patch] appending to a capture


>>>>> "Sam" == Sam Roberts <vieuxtech <at> gmail.com> writes:
    >> Yeah, I'd rather that we have a good set of pcap manipulation
    >> tools.  Maybe we just need better pointers to mergecap and
    >> editcap?

    Sam> I don't see extensions to libpcap and a good set of tools as an
    Sam> either/or thing.

    Sam> I'd be pretty happy to see the capabilities of tools such as
    Sam> mergecap, editcap, and tcpslice presented as C callable APIs.

So, you'd like to have pcap_reopen() then?

I think that if give the function a new name, it will be less surprising
to people.  

--

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr <at> sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.
Permalink | Reply | 3 comments |
headers
Guy Harris | 2 Jun 2011 19:50
Picon
Favicon

Re: libpcap1.1.1 truncates UDP payload, ring buffer problem?


On Jun 1, 2011, at 5:58 AM, mold2010 wrote:

> I tried libpcap1.1.1 release libpcap_1_1rel0 from https://github.com/mcr/libpcap. But found the
same issue. Where can I get the 1.2 branch? Is it git hub: libpcap?

Both the 1.2 branch and the trunk can be found on bpf.tcpdump.org, and probably on github as well:

	http://www.tcpdump.org/#source
Permalink | Reply | 0 comments |
headers
Guy Harris | 2 Jun 2011 19:57
Picon
Favicon

Re: [PATCH] ifSpeed in sFlow is 64 bits not 32


On May 27, 2011, at 5:59 PM, Rick Jones wrote:

> The ifSpeed field of a generic interface counter in sFlow is 64 bits.
> The "overlay" definition in print-sflow.c is correct, but the actual
> extract for printing is using EXTRACT_32BITS rather than EXTRACT_64BITS,
> which leads to an incorrect report for speed.

Checked into the trunk and 4.2 branches (with a fix to the format string to use PRIu64).
Permalink | Reply | 2 comments |
headers
Rick Jones | 2 Jun 2011 20:10
Picon
Favicon

Re: [PATCH] ifSpeed in sFlow is 64 bits not 32

On Thu, 2011-06-02 at 10:57 -0700, Guy Harris wrote:
> On May 27, 2011, at 5:59 PM, Rick Jones wrote:
> 
> > The ifSpeed field of a generic interface counter in sFlow is 64 bits.
> > The "overlay" definition in print-sflow.c is correct, but the actual
> > extract for printing is using EXTRACT_32BITS rather than EXTRACT_64BITS,
> > which leads to an incorrect report for speed.
> 
> Checked into the trunk and 4.2 branches 

Excellent.

> (with a fix to the format string to use PRIu64).

Oops - I keep forgetting that all my compiles are 64 bit and so don't
remember to check for such things.

rick

> -
> This is the tcpdump-workers list.
> Visit https://cod.sandelman.ca/ to unsubscribe.
Permalink | Reply | 1 comment |

Gmane