[pcap-ng-format] Does the block total length include any padding required by the contents?

[Jasper Bongertz]

On 12.05.2012 17:42, Richard Sharpe wrote:
> Hi,
>
> In writing code to parse pcapng files so I can pipe a pacpng capture
> into Wireshark I came across an interesting problem with the
> icmp2.ntar file here: http://wiki.wireshark.org/Development/PcapNg
>
> The Packet blocks have a block total length that does not seem to
> include the padding required by the block, however, it seems that the
> block total length in the SHB does including the padding in the blocks
> it describes.
>
> Each PB is actually 112 bytes long (the captured frame is 78 bytes but
> it is padded to 80 bytes.) The block total length is listed as 110
> bytes (0x6E) not 112 (0x70).
>
> Can someone clarify whether or not the block total length should
> include the padding. If not, it complicates my parser slightly.
>
I encountered the same problem and had to adjust my parsing code to work
with it - I think I tested against the same file as well, because it was
the only one I could find that still had the deprecated packet block
format. I think the file is kind of "damaged" since it should have been
written with the block total lenght including the padding - the padding
is part of the block, so it has to be included in its size IMHO.

I put some workaround code into my parser to automatically fix the
length if padding isn't included, but I think we should not see many
more packet block headers in trace files since they are replaced by
enhanced packet blocks and simple packet blocks.

It would be good to clarify in the specs that the padding is included
though.