[ntar-workers] PCAP-NG / Interface ID size / Drops Counter size ?
Gianluca Varenni
gianluca.varenni at cacetech.com
Wed Mar 22 06:55:33 GMT 2006
Tonight I played a bit with the specification, the result is available at
http://www.winpcap.org/ntar/draft/PCAP-DumpFileFormat.html (or .xml, if you
prefer).
Here is a quick list of the things I changed/fixed/...
- Added a preliminary version of Appendix C, detailing the Standardized Link
Types.
- Added a preliminary version of Appendix B, detailing the Standardized
Block Type codes.
- Added the Enhanced Packet Block in section 2.2. Fixed a typo in the list:
it's Interface Statistics Block, and not Capture Statistics Block.
- Fixed some minor typos in the document.
- Fixed an error in Packet Block: option pack_hash should have code 3.
- Added the definition of the Enhanced Packet Block.
- Added option if_tsoffset in the Interface Description Block.
The most important things are the definition of the Enhanced Packet Block
(in the previous mail I think I was drunk, as I wrote "Enhanced Interface
Description Block", while the block that needed to be "patched" was the
packet one), and a rather incomplete definition of Appendix B and C related
to link type codes and Block Type Codes.
Big open issues:
- what is the correct way to interpret the timestamps in the current packet
block? Seconds/sub-seconds or high/low part of sub-seconds??. Noone seems to
have a clue, and the spec is quite vague on this in both the PacketBlock and
the EnhancedPacketBlock
- better definition of the Link types in appendix C. Probably we should work
on the link types using the DLT_xxx values used by libpcap (the current list
in appendix C is an attempt towards that, I was lazy enough to put only the
first 10 values).
- other things that do not come to my mind tonight...
Have a nice day
GV
----- Original Message -----
From: "Gianluca Varenni" <gianluca.varenni at cacetech.com>
To: <ntar-workers at winpcap.org>
Cc: <risso at polito.it>
Sent: Wednesday, March 08, 2006 3:38 PM
Subject: Re: [ntar-workers] PCAP-NG / Interface ID size / Drops Counter size
?
>
> ----- Original Message -----
> From: "Hannes Gredler" <hannes at juniper.net>
> To: <ntar-workers at winpcap.org>
> Cc: <risso at polito.it>
> Sent: Sunday, March 05, 2006 10:41 PM
> Subject: Re: [ntar-workers] PCAP-NG / Interface ID size / Drops Counter
> size ?
>
>
>>
>>
>> Gianluca Varenni wrote:
>>> First of all, sorry for the long delay, I was really busy last weeks at
>>> work.
>>> Since captures do not span years (I think they span hours, days), an
>>> approach that came to my mind, *if* we want to use 64bit instead of 128
>>> bits for timestamps, is:
>>>
>>> 1. use timestamp(low)/(high) as the *actual* 32bit low/high parts of a
>>> 64 bit counter
>>> 2. maintain the spec of the precision of this timestamp as it is now in
>>> the IDB
>>> 3. add an option in the IDB that specifies an (optional) offset for the
>>> timestamps of packets related to that interface
>>>
>>> In this way you can for example store a capture with picosecond
>>> precision, with a maximum length of about 5000 hours (if my computations
>>> are not wrong).
>>>
>>> Any opinions on this?
>>
>> gianluca,
>>
>> i do think this is a nice tradeoff b/w overhead and extensibility and
>> looks
>> good to me.
>
> Since noone else objected to my proposal (well, noone else replied...),
> I'll add a new option within the IDB to account for this timestamp offset.
>
> It should be something like (it does not take into account the
> representation of timestamps in blocks different from packet blocks):
>
> Option name: if_tsoffset
> Code: 14
> Length: 8 (bytes)
> Description: a 64bit integer that specifies an offset (in seconds) that
> must be added to the
> timestamp of each packet to obtain the absolute timestamp of
> a packet. If the
> option is missing, the timestamps stored in the packet must
> be considered absolute
> timestamps.
>
> The question that still remains open is "what is the correct way to
> interpret the timestamps in the current packet block? Seconds/sub-seconds
> or high/low part of sub-seconds??" I'd prefer the latter.
>
>> - another question: did you have a look at the 16-bit vs 32-bit
>> counter/index
>> issues that i was talking about earlier - any bright ideas would be
>> welcome.
>
> I still think the best idea is to define a new IDB (Enhanced IDB??) with
> the layout I proposed in my other mail two weeks ago:
>
> 0 1 2 3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Interface ID |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Timestamp (High) |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Timestamp (Low) |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Captured Len |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Packet Len |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> / /
> / Packet Data /
> / /* variable length, aligned to 32 bits */ /
> / /
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> / /
> / Options (variable) /
> / /
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> The drop count will be saved as a 64 bit value in an option.
>
> I'd prefer to have the dropped packet count as an option in order to
> reduce
> the block headers overhead in case the user does not want to save this
> information.
>
> Does it sound reasonable to you?
>
> If noone objects on such approach, I'll amend the specification with this
> new block. (BTW, I think I should find a way to track reviews the "spec"
> so that anyone can see the changes...).
>
> Have a nice day
> GV
>
>>
>> tx,
>>
>> /hannes
>> _______________________________________________
>> ntar-workers mailing list
>> ntar-workers at winpcap.org
>> https://www.winpcap.org/mailman/listinfo/ntar-workers
>>
>
> _______________________________________________
> ntar-workers mailing list
> ntar-workers at winpcap.org
> https://www.winpcap.org/mailman/listinfo/ntar-workers
>
More information about the ntar-workers
mailing list