On Fri, Jun 3, 2011 at 9:49 PM, Darren Reed wrote:
> On 3/06/11 05:24 PM, Guy Harris wrote:
>>
>> On Jun 3, 2011, at 3:13 PM, Darren Reed wrote:
>>
>>
>>>
>>> Because for every packet that is appended you need to do:
>>> 1. open(2)
>>> 2. read(2)
>>> 3. seek(2)
>>> 4. write(2)
>>> 5. close(2)
>>>
> "Guy" == Guy Harris writes:
>> So, you'd like to have pcap_reopen() then?
Guy> What would pcap_reopen() do? Mark's new API has a reasonable
Guy> name given what it does:
Guy>1) it returns a pcap_dumper_t, not a pcap_t, so it
Guy> should have "dump" in its name
On 3/06/11 05:24 PM, Guy Harris wrote:
On Jun 3, 2011, at 3:13 PM, Darren Reed wrote:
Because for every packet that is appended you need to do:
1. open(2)
2. read(2)
3. seek(2)
4. write(2)
5. close(2)
Really?
Why can't you do
open(2)
read(2)
seek(2)
On Jun 1, 2011, at 12:43 PM, Michael Richardson wrote:
> So, you'd like to have pcap_reopen() then?
What would pcap_reopen() do? Mark's new API has a reasonable name given what
it does:
1) it returns a pcap_dumper_t, not a pcap_t, so it should have "dump"
in its name;
2) it
On Jun 3, 2011, at 3:13 PM, Darren Reed wrote:
> Because for every packet that is appended you need to do:
> 1. open(2)
> 2. read(2)
> 3. seek(2)
> 4. write(2)
> 5. close(2)
Really?
Why can't you do
open(2)
read(2)
seek(2)
write(2)
in pcap_dump_append(), and th
On 1/06/11 08:10 AM, Mark Johnston wrote:
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
On 1/06/11 12:43 PM, Michael Richardson wrote:
"Sam" == Sam Roberts 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 a
On Wed, Jun 1, 2011 at 9:24 AM, Gerald Combs wrote:
> 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
> "Sam" == Sam Roberts 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
On Wed, Jun 1, 2011 at 11:13 AM, Michael Richardson 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
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[
] m.
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
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 associa
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 pur
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
Hello all,
I submitted a patch to the sourceforge tracker a while ago and didn't
receive any response. It adds a dump append function which verifies that
we only append if the link-layer type is the same as that in the capture
to append to. I submitted this based on a (rather old) thread:
http://
16 matches
Mail list logo
