[pcap-ng-format] Moving forward with pcap-ng

[Richard Sharpe]

On Tue, Jun 26, 2012 at 11:57 AM, Guy Harris <guy at alum.mit.edu> wrote:
>
> On Jun 26, 2012, at 11:39 AM, Richard Sharpe wrote:
>
>> There are (hardware) groups out there who might be encouraged to use
>> the standard if certain changes were made to formats. For example,
>> switch/aggregator/etc vendors might like the actual packet data in an
>> enhanced packet block (or a new block type) to appear early in each
>> encapsulated packet. That is, packet data comes immediately after the
>> 8-byte header.
>
> New block type, please.  Let's not change the way a block with a
> block type value of 6 is to be read.

Yes, you are correct. That means we can move forward with the
completion of Version 1.0 of the spec.

>> This allows such users to reduce the buffering required and start
>> pushing the frame data out onto the wire as soon as they have
>> assembled the frame to be sent. Once the frame data has been sent they
>> can then push out the options (capture timestamp etc) which they can
>> assemble while they are transmitting the frame data.
>>
>> Of course, I might be off base here, but assembling the additional 20
>> bytes required by the interface ID, timestamp high and timestamp low,
>> packet len and captured len might be a problem.
>
> Note that they have to know the captured length before they start pushing
> the packet out, as the total block length is the captured length, plus the
> length of the extra data, plus padding, and is thus dependent on the
> captured length.  *Assembling* that extra data might be a problem, but
> you still have to at least *know* the captured length before you start.

Not really. If they were told to only capture, say the first 128 bytes
of the packet, they can assemble the block header on the basis that
they will have 128 bytes plus the block header and options, if any.

If the captured data is actually shorter than 128 bytes, then it does
not matter that there is padding in this special block type, and good
parsers should ignore it (the captured length could be shorter than
block len minus [all the other overhead].)

Of course, it is not clear that this is useful.

-- 
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)