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 least for
-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 the
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
- 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 say that haven't used XML
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
decoded frame
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
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. Moreover, I'll like to
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 believe this
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
- 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 include, for received packets, an
indication
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 reasonably
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 block
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
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
-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
15 matches
Mail list logo
