Re: proposed new pcap format

[Darren Reed <darrenr () reed wattle id au>]

In some email I received from Michael Richardson, sie wrote:
> > > > > > "Darren" == Darren Reed <darrenr () reed wattle id au> writes:
>     >> This is what I would propose as revision.
>     >> Note that the pcap1_packet_header is present on every packet. One can
>     >> merge pcap files together with "cat" if one likes.
>     >>
>     >> A suggestion was made to accomodate the nano-second resolution from AIX.
>     >> Can you tell me what they do for that? just more bits, sure, but is
>     >> there a nano-seconds (32-bits, I guess) + seconds (64 bits?).
>     >>
>     >>
>     >> enum pcap1_info_types {
>     >> PCAP_DATACAPTURE,
>     >> PCAP_TIMESTAMP,
>     >> };
>
>     Darren> Can I please also ask for a PCAP_PRIVATE that is as follows:
>
> the intention is that tools will skip/copy types they don't understand,
> and that the list will be open to extension. Probably the actual 4-byte
> encodings of the types will be 4-printable characters whenever
> possible.

This is kind of why I wanted to suggest this...I've been much more
expansive on the problem below :)

>     Darren> struct pcap1_info_private {
>     Darren> char pinfo_guid[4+2+2+8];
>     Darren> char pinfo_data[0];
>     Darren> }
>
>   Sure, but what is it for?
>   If it is private, do you want to tell us :-)

No, it's not that private :)  What I'm proposing here is a way in
which people can put custom data into the pcap files without having
too be too concerned about what values are safe for the type field
and what values aren't.

By using a BIG field (such as the size of the guid_t Microsoft uses
to identify programs, objects, etc), it gives people scope to put
something meaningful in the record type.

I suppose another side of this might be to do like this:

enum pcap1_info_types {
        PCAP_DATACAPTURE,
        PCAP_TIMESTAMP,
        PCAP_PRIVATE_BASE=0x80000000,
};

and in so doing, effectively reserve 0-0x7fffffff for your registry
and 0x80000000-0xffffffff for private use by people.  Only problem
I have is the size of the field being large enough.

Why wouldn't it be large enough?  Well, IPv6 is 128bits in size mainly
because of perceived "administration overheads" so why not 128bits here?

My general problem with relying on "skipping unrecognised fields"
with the flat 32bit space is that the number space isn't big enough
to make the liklihood of a capture from one app. being incorrectly
used on another low.

Also, I see this as two different problems.  In the first, you have
a registry of generic type fields people may find in a libpcap file.
On the other, you have application specific data that has been
inserted for some specific purpose.

And having said that, my suggestion above could lead to a higher
occurance of problems through people using PCAP_PRIVATE_BASE+n
(where n is 0..9, say) for their own purposes and too many apps
interpreting the data from others incorrectly.  Using a guid and
including a 128bit RNG (md5 of some system specific things?)
program might lead to fewer instances of programs interpreting
"private" data incorrectly ?

I'm saying all this because I'm working on an application where
we'd love to put private data in the libpcap files :)

Darren
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:tcpdump-workers-request () tcpdump org?body=unsubscribe