In some email I received from Jefferson Ogata, sie wrote:
> Darren Reed wrote:
> > In some email I received from Michael Richardson, sie wrote:
> >> Prooving what? that you aren't being lied to? By whom?
> >> What is the thread model for this? What does having the kernel digital
> >>sign stuff ga
Darren Reed wrote:
In some email I received from Michael Richardson, sie wrote:
Prooving what? that you aren't being lied to? By whom?
What is the thread model for this? What does having the kernel digital
sign stuff gain you? Who would lie to you in such a way that they
couldn't also have the ke
In some email I received from Michael Richardson, sie wrote:
> {Darren, you are sending to tcpdump-workers-owner, from the SMTP
> envelope. I think my MTA is canonicalizing something in a way I don't
> want it to. It isn't the lists' fault}
Thanks, fixed my alias.
> > "Darren" == Darren Ree
On Tue, Apr 20, 2004 at 06:16:48PM -0700, Michael Richardson wrote:
> Darren> btw, is it at all easily possible to get the 802.3 checksum
> Darren> into captured data ?
>
> On some OSes you ask for that. Not on BSD AFAIK, yes, with PF_PACKET
> on Linux.
Some BSDs give it to you, at lea
> "Stephen" == Stephen Donnelly <[EMAIL PROTECTED]> writes:
Stephen> Instead of trying to store the number of significant
Stephen> figures in some base, how about storing the effective clock
Stephen> timestamp frequency in Hz? This gives an indication of
Stephen> resolution as
-BEGIN PGP SIGNED MESSAGE-
{Darren, you are sending to tcpdump-workers-owner, from the SMTP
envelope. I think my MTA is canonicalizing something in a way I don't
want it to. It isn't the lists' fault}
> "Darren" == Darren Reed <[EMAIL PROTECTED]> writes:
>> Are we worrying abou
-BEGIN PGP SIGNED MESSAGE-
> "Darren" == Darren Reed <[EMAIL PROTECTED]> writes:
Darren> In some email I received from Guy Harris, sie wrote:
>> On Apr 13, 2004, at 3:38 PM, Darren Reed wrote: > In each case
>> the specification defines support for a number of > different
-BEGIN PGP SIGNED MESSAGE-
> "Fulvio" == Fulvio Risso <[EMAIL PROTECTED]> writes:
>> I agree, but since we a are trying to define a standard,
Fulvio> I don't think the IETF is willing to define a standard for
Fulvio> this. I feel better to say "we would like to document
-BEGIN PGP SIGNED MESSAGE-
> "Guy" == Guy Harris <[EMAIL PROTECTED]> writes:
>> What I'd like to see hashed, by the kernel, is the data it
>> provides to the user application. Depending on the purpose, this
>> has better trustworthiness, I feel. libpcap may decide to thro
-BEGIN PGP SIGNED MESSAGE-
> "Fulvio" == Fulvio Risso <[EMAIL PROTECTED]> writes:
Fulvio> Personally I don't like to transform the Section Header
Fulvio> Block from a MARKER to a CONTAINER. I don't like to rewind
Fulvio> the file in case of large capture in order to updat
Stephen Donnelly wrote:
When capturing network data at hundreds of megabytes per second for
extended periods and hence dealing with hundreds of gigabytes of
captured data at a time, even 33% overhead is very expensive in storage
space and disk bandwidth, as well as the cpu time required to perfo
Jefferson Ogata wrote:
50% extra space and 50% extra disk bandwidth cost? So my 250
Megabyte per second
pcap stream to disk becomes 375MB/s?
...
Raw packet data would typically be base64-encoded. This expands data by
33%; three octets become four. You don't have to write one octet as two.
In any
Ronnie Sahlberg wrote:
Yes, fully fledged decoded captures would use a lot of extra disk, but a
raw no-frills capture could be recorded with maybe only 50% or so
overhead.
50% extra space and 50% extra disk bandwidth cost? So my 250 Megabyte per
second pcap stream to disk becomes 375MB/s?
I would
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Hannes
> Gredler
> Sent: mercoledi 14 aprile 2004 21.05
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]; Loris Degioanni
> Subject: Re: [tcpdump-workers] Proposed new pcap for
On Apr 14, 2004, at 12:06 AM, Jefferson Ogata wrote:
Additional protocol dissectors for protocols unknown to
tcpdump/tethereal could be written in any language with XML support
(preferably event-based). In fact, many protocol analyzers could be
written directly in XSLT/XPath and processed using
On Wed, Apr 14, 2004 at 03:06:09AM -0400, Jefferson Ogata wrote:
[ ... ]
| I think we should take a hard look at
| whether it's really appropriate to define yet another hard binary file
| format when XML can provide the same
On Wed, 2004-04-14 at 00:06, Jefferson Ogata wrote:
>
> I'm suggesting the pcap storage format be XML. A raw capture, without using
> protocol dissectors, would just be a sequence of base64-encoded (perhaps) frames
> and metadata.
But once you're using raw base64-encoded (or whatever), you're lo
On Wed, Apr 14, 2004 at 08:25:25AM +0200, Fulvio Risso wrote:
| I agree with Loris.
| I know that this flag would be extremely useful, but there are no guarantees
| that you're able to get this info from the NIC / NIC driver.
| Perhaps, what we should to is to use 2 bits for each flag, where the f
Jefferson,
> Fulvio Risso wrote:
> >>[mailto:[EMAIL PROTECTED] Behalf Of Stephen
> >>Donnelly
> >>
> >>Jefferson Ogata wrote:
> >>>Yes, fully fledged decoded captures would use a lot of extra
> >>disk, but a
> >>>raw no-frills capture could be recorded with maybe only 50% or
> >>so overhead.
> >>
On Wed, Apr 14, 2004 at 09:23:52AM +0200, Fulvio Risso wrote:
> If everything is "optional", two compliant implementations cannot exchange
> data.
If the hash is an option (which it should be!), compliant
implementations should handle hash values they know about and just
ignore those that they don
Ronnie Sahlberg wrote:
Given all the desirable options people are looking for in this, and the
need for future growth, I think we should seriously consider an
XML-based format. Besides making it easy, format-wise, to include many
optional features and types of metadata, programs could also embed
de
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Ronnie
> Sahlberg
> Sent: mercoledì 14 aprile 2004 13.19
> To: [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> Subject: Re: [tcpdump-workers] Proposed new pcap format
>
>
>
>
> > Given all the desirable options people are looking for in this, and the
> > need for future growth, I think we should seriously consider an
> > XML-based format. Besides making it easy, format-wise, to include many
> > optional features and types of metadata, programs could also embed
> > decod
- Original Message -
From: "Jefferson Ogata"
Sent: Wednesday, April 14, 2004 6:29 PM
Subject: Re: [tcpdump-workers] Proposed new pcap format
> Ronnie Sahlberg wrote:
> > I dont see really the benefit from using XML at all.
>
> Usually I find that people who
Ronnie Sahlberg wrote:
I dont see really the benefit from using XML at all.
Usually I find that people who say that haven't used XML for anything significant.
It is just another file format and other well defined TLV fileformats are
just as extensible.
The only aplications ever reading pcap files
Fulvio Risso wrote:
[mailto:[EMAIL PROTECTED] Behalf Of Stephen
Donnelly
Jefferson Ogata wrote:
Yes, fully fledged decoded captures would use a lot of extra
disk, but a
raw no-frills capture could be recorded with maybe only 50% or
so overhead.
50% extra space and 50% extra disk bandwidth cost? So
- Original Message -
From: "Stephen Donnelly"
Sent: Wednesday, April 14, 2004 12:38 PM
Subject: Re: [tcpdump-workers] Proposed new pcap format
> > Yes, fully fledged decoded captures would use a lot of extra disk, but a
> > raw no-frills capture could be recorded
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Darren
> Reed
> Sent: mercoledi 14 aprile 2004 0.38
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: [tcpdump-workers] Proposed new pcap format
>
>
> In
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Stephen
> Donnelly
> Sent: mercoledi 14 aprile 2004 4.38
> To: [EMAIL PROTECTED]
> Subject: Re: [tcpdump-workers] Proposed new pcap format
>
>
> Jefferson Ogata wrote:
>
Hi Jefferson.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Jefferson
> Ogata
> Sent: mercoledi 14 aprile 2004 1.10
> To: [EMAIL PROTECTED]
> Subject: Re: [tcpdump-workers] Proposed new pcap format
>
>
> Darren Reed wrot
Christian Kreibich wrote:
Are you suggesting an xml-based pcap, or xmlified tcpdump output?
If you mean the former, I think the problem with this approach is that
in order to be able to write out a file in the first place, the
structure of the packet content has to be understood by libpcap (so tha
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Loris
> Degioanni
> Sent: martedì 13 aprile 2004 19.53
> To: [EMAIL PROTECTED]
> Subject: Re: [tcpdump-workers] Proposed new pcap format
>
>
> Ronnie,
>
> >
&g
Hi.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Loris
> Degioanni
> Sent: martedì 13 aprile 2004 20.23
> To: [EMAIL PROTECTED]
> Subject: Re: [tcpdump-workers] Proposed new pcap format
>
>
> Hi,
>
>
> > In
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Loris
> Degioanni
> Sent: martedì 13 aprile 2004 20.18
> To: [EMAIL PROTECTED]
> Subject: Re: [tcpdump-workers] Proposed new pcap format
>
>
> Hi,
>
>
> >
On Tue, 2004-04-13 at 16:09, Jefferson Ogata wrote:
>
> Something keeps bugging me, and I just want to throw it out there for
> the mad dogs to tear into little bloody pieces:
>
> Given all the desirable options people are looking for in this, and the
> need for future growth, I think we should
Jefferson Ogata wrote:
Something keeps bugging me, and I just want to throw it out there for
the mad dogs to tear into little bloody pieces:
Given all the desirable options people are looking for in this, and the
need for future growth, I think we should seriously consider an
XML-based format.
Guy Harris wrote:
That might not require us to choose a default, however, as long as the
kernel can tell libpcap which hash value it's providing (if any). It
might, however, mean that we should choose a hash value that, for kernel
hashing, is considered "adequate", and recommend that capture me
Darren Reed wrote:
On the contrary, it's a trivial matter, really, to add more.
Is there a "default" hashing method for SSL ?
Or IPSec ?
Or S/MIME ?
No.
In each case the specification defines support for a number of different
hashes, of varying strengths and the choice is left to the end user to
d
On Apr 13, 2004, at 3:38 PM, Darren Reed wrote:
In each case the specification defines support for a number of
different
hashes, of varying strengths and the choice is left to the end user to
decide on what they wish to use. I don't see why libpcap should be any
different.
If the hash value is g
In some email I received from Loris Degioanni, sie wrote:
> > Today, some people might want MD-5, others SHA-1 and in the future,
> > there may be other hashing algorithms that are better to use. And
> > there are times when we might want it off (algorithm 0, for example.)
> >
> > As such, I belie
On Apr 13, 2004, at 6:58 AM, Darren Reed wrote:
What I'd like to see hashed, by the kernel, is the data it provides
to the user application. Depending on the purpose, this has better
trustworthiness, I feel. libpcap may decide to throw away that hash
and include its own in the dump file.
I'm not
Hi,
> In some email I received from Loris Degioanni, sie wrote:
> [ Charset ISO-8859-1 unsupported, converting... ]
> > Ok, I'm going to add a 8-byte hash option for the packet block. Can
anybody
> > suggest the hashing algorithm?
>
> You obviously sent this before reading another email I sent on
Hi,
>
> - Original Message -
> From: "Loris Degioanni"
> Sent: Monday, April 12, 2004 2:55 PM
> Subject: Re: [tcpdump-workers] Proposed new pcap format
>
>
>
> > Essentially, what you propose is that the SHB CONTAINS a section rather
> than
Michael,
> -BEGIN PGP SIGNED MESSAGE-
>
>
> > "Loris" == Loris Degioanni <[EMAIL PROTECTED]> writes:
> Loris> It depends on what "our scribe" means: I'll be around the
> Loris> world during the next month, and I'll not be able to work
> Loris> regularly on the document. Mo
Ronnie,
>
> - Original Message -
> From: "Loris Degioanni"
> Sent: Monday, April 12, 2004 2:56 PM
> Subject: Re: [tcpdump-workers] Proposed new pcap format
>
>
> > > I'd prefer a general flag field, which would include a direction
> > &
In some email I received from Michael Richardson, sie wrote:
-- Start of PGP signed section.
>
> > "Darren" == Darren Reed <[EMAIL PROTECTED]> writes:
> Darren> Today, some people might want MD-5, others SHA-1 and in the
> Darren> future, there may be other hashing algorithms that are
- Original Message -
From: "Michael Richardson"
Sent: Tuesday, April 13, 2004 12:58 AM
Subject: Re: [tcpdump-workers] Proposed new pcap format
> -BEGIN PGP SIGNED MESSAGE-
>
>
> >>>>> "Darren" == Darren Reed writes:
> Darren
- Original Message -
From: "Michael Richardson"
Sent: Tuesday, April 13, 2004 12:52 AM
Subject: Re: [tcpdump-workers] Proposed new pcap format
> -BEGIN PGP SIGNED MESSAGE-
>
>
> >>>>> "Darren" == Darren Reed &l
-BEGIN PGP SIGNED MESSAGE-
> "Darren" == Darren Reed <[EMAIL PROTECTED]> writes:
Darren> Today, some people might want MD-5, others SHA-1 and in the
Darren> future, there may be other hashing algorithms that are
Darren> better to use. And there are times when we might wan
-BEGIN PGP SIGNED MESSAGE-
> "Darren" == Darren Reed <[EMAIL PROTECTED]> writes:
>> Oh, I forgot.
>>
>> Another useful thing to have is an option for the packet block
>> where one would store a reasonably collission-safe 8-byte hash of
>> the packet data.
>>
-BEGIN PGP SIGNED MESSAGE-
> "Christian" == Christian Kreibich <[EMAIL PROTECTED]> writes:
>> That's a nice feature, and one we should try to maintain if
>> possible.
Christian> There's another thing I'd like to point out: the new
Christian> scheme, in its current sta
-BEGIN PGP SIGNED MESSAGE-
> "Loris" == Loris Degioanni <[EMAIL PROTECTED]> writes:
Loris> It depends on what "our scribe" means: I'll be around the
Loris> world during the next month, and I'll not be able to work
Loris> regularly on the document. Moreover, I'll like to u
In some email I received from Loris Degioanni, sie wrote:
[ Charset ISO-8859-1 unsupported, converting... ]
> Ok, I'm going to add a 8-byte hash option for the packet block. Can anybody
> suggest the hashing algorithm?
You obviously sent this before reading another email I sent on this.
Today, so
- Original Message -
From: "Loris Degioanni"
Sent: Monday, April 12, 2004 2:56 PM
Subject: Re: [tcpdump-workers] Proposed new pcap format
> > I'd prefer a general flag field, which would include a direction
> > indication (which might also includ
- Original Message -
From: "Loris Degioanni"
Sent: Monday, April 12, 2004 2:55 PM
Subject: Re: [tcpdump-workers] Proposed new pcap format
> Essentially, what you propose is that the SHB CONTAINS a section rather
than
> MARKING its beginning. The SHB, in fact, as
Ok, I'm going to add a 8-byte hash option for the packet block. Can anybody
suggest the hashing algorithm?
Loris
> In some email I received from Ronnie Sahlberg, sie wrote:
> > Oh, I forgot.
> >
> > Another useful thing to have is an option for the packet block where one
> > would store
> > a re
Hi,
> > 3.3
> > the packet block has a description of which interface the packet was
> > captured on.
> > It should also have a mandatory flag that describes whether we picked
the
> > packet from Rx or Tx on the interface.
> > This should be a mandatory field in the header (1 bit) and not
> > opti
Hi,
> Hi list,
> Im pretty new to this discussion (only joined so i could participate in
this
> discussion)
>
> I have looked at http://www.tcpdump.org/pcap/pcap.html
> and have some comments.
>
>
> 3.1 "this makes the parsing of the file slower but it permits to append
> several capture dumps at
In some email I received from Guy Harris, sie wrote:
> On Sat, Apr 10, 2004 at 04:39:41AM +1000, Darren Reed wrote:
> > I'll agree that this, as part of the per-packet header, would be a useful
> > addition to the pcap format. No need for chained hashing, just per-record.
>
> Part of the packet b
On Sat, Apr 10, 2004 at 04:39:41AM +1000, Darren Reed wrote:
> I'll agree that this, as part of the per-packet header, would be a useful
> addition to the pcap format. No need for chained hashing, just per-record.
Part of the packet block header, or an option in the packet block? I'd
vote for th
In some email I received from Ronnie Sahlberg, sie wrote:
> Oh, I forgot.
>
> Another useful thing to have is an option for the packet block where one
> would store
> a reasonably collission-safe 8-byte hash of the packet data.
>
> This would make it much easier to compare two different capture f
On Fri, Apr 09, 2004 at 06:29:42PM +1000, Ronnie Sahlberg wrote:
> A capture application could then initially write length==0 when it first
> writes out the SHB and then not seek() back and write the real length until
> it closes the SHB.
...unless it's writing to a pipe; I think people sometimes
Oh, I forgot.
Another useful thing to have is an option for the packet block where one
would store
a reasonably collission-safe 8-byte hash of the packet data.
This would make it much easier to compare two different capture files to see
where packets are missing etc.
-
This is the tcpdump-worker
Hi list,
Im pretty new to this discussion (only joined so i could participate in this
discussion)
I have looked at http://www.tcpdump.org/pcap/pcap.html
and have some comments.
3.1 "this makes the parsing of the file slower but it permits to append
several capture dumps at the same file"
-
On Tue, 6 Apr 2004, Loris Degioanni wrote:
> It depends on what "our scribe" means: I'll be around the world during the
> next month, and I'll not be able to work regularly on the document.
> Moreover, I'll like to understand if the list agrees with the idea of
> proposing an Internet Draft that d
Hi,
> -BEGIN PGP SIGNED MESSAGE-
>
>
> Loris had previously written up an ID on a proposed pcap format.
> It is similar, but not identical to what I had proposed.
>
> It is in xml2rfc (rfc2629) format.
> I can't say if the IETF would or should ever consider publishing it.
> I think it is l
On Apr 5, 2004, at 10:39 PM, Ryan Mooney wrote:
What about adding the concept of arbitrary meta-packets that can
sit anywhere in the capture stream. These could be used to encode
comments, and other meta-data.
In Michael Richardson's proposal, a capture file is a sequence of
records, each of whi
There are probably good reasons why what I'm suggesting here is,
as stated, a bad idea; but since the packet storage format is up
for discussion I thought I'd throw this out to see if it peaks
anyones interest.
What about adding the concept of arbitrary meta-packets that can
sit anywhere in the c
-BEGIN PGP SIGNED MESSAGE-
Loris had previously written up an ID on a proposed pcap format.
It is similar, but not identical to what I had proposed.
It is in xml2rfc (rfc2629) format.
I can't say if the IETF would or should ever consider publishing it.
I think it is likely out of scope f
On Fri, 2 Apr 2004, Guy Harris wrote:
>
> On Mar 25, 2004, at 9:31 AM, Richard Sharpe wrote:
>
> > One of the items I would like support for in a new format is comments.
> > That is, the ability to add textual comments to frames. These comments
> > would be ignored by tools that do not understan
On Mar 27, 2004, at 9:15 PM, Michael Richardson wrote:
Do these need to be in every packet? Maybe it is just meta-data that
needs to be added at the beginning, perhaps along with the filter code.
The packet direction and, for received packets, an indication of how it
was received, would be per
> "Darren" == Darren Reed <[EMAIL PROTECTED]> writes:
Darren> What's the _real_ list address? The web page still has:
Darren> [EMAIL PROTECTED] Some of my emails seem to go
Darren> missing rather to the list :-/ There's also
Darren> [EMAIL PROTECTED]
Darren> [EMAIL PROTEC
In some email I received from Christian Kreibich, sie wrote:
> [I've tried to get this to the list about four times now and it always
> came back with a different reason -- I hope this one will make it to
> the new list. Thanks.]
What's the _real_ list address? The web page still has:
[EMAIL PROT
[I've tried to get this to the list about four times now and it always
came back with a different reason -- I hope this one will make it to
the new list. Thanks.]
On Wed, 2004-03-24 at 03:31, Jefferson Ogata wrote:
> Michael Richardson wrote:
> > This is what I would propose as revision.
> > Note
On Thu, Mar 25, 2004 at 09:25:43AM -0800, Richard Sharpe wrote:
| On Fri, 26 Mar 2004, Darren Reed wrote:
|
| > > okay, divide the 32-bit space into two 16-bit spaces.
| > > vendor 0 will be reserved.
| > > tcpdump.org will be vendor 1.
| > >
| > > vendor 0x will be reserved (for the
-BEGIN PGP SIGNED MESSAGE-
> "Guy" == Guy Harris <[EMAIL PROTECTED]> writes:
Guy> On Mar 24, 2004, at 7:08 AM, Michael Richardson wrote:
>> okay, but there is more than just in/out.
>>
>> enum pcap1_probe {
>> INBOUND =1,
>> OUTBOUND =2,
>> FORWARD =3,
-BEGIN PGP SIGNED MESSAGE-
> "Hannes" == Hannes Gredler <[EMAIL PROTECTED]> writes:
Hannes> | okay, but there is more than just in/out.
Hannes> |
Hannes> | enum pcap1_probe {
Hannes> | INBOUND =1,
Hannes> | OUTBOUND =2,
Hannes> | FORWARD =3,
Hanne
-BEGIN PGP SIGNED MESSAGE-
> "Darren" == Darren Reed <[EMAIL PROTECTED]> writes:
Darren> I suppose I'm not so much concerned about it being "private"
Darren> as it being unique.
Darren> Maybe a vendor field and vendor sub-type field would be
Darren> useful ? That'd gi
-BEGIN PGP SIGNED MESSAGE-
> "Richard" == Richard Sharpe <[EMAIL PROTECTED]> writes:
Richard> That is, the ability to add textual comments to
Richard> frames. These comments would be ignored by tools that do
Richard> not understand them, but they would be displayed by tool
79 matches
Mail list logo
