The length of Custom Block's Custom Data?

[winking324]

Hi,

I wrote a simple ntar reader in C++, and how to directly get the length of custom data when parsing the Custom Block?

My repo: ntar-reader and this part of the parsing code is in ntar-reader/src/block_custom.cpp.

[guyharris]

If a block supports options, you cannot have the length of the non-options part of the block contents be derived solely from the block total length, as that length includes the length of the options - you must have some other mechanism that allows the length of the non-options part of the block to be determined.

Thus, the format for a given PEN's custom block must either:

1. not support any options, including OPT_COMMENT, so that the length of the Custom Data field is (block total length - 16) or
2. be in a format that contains data allowing, for all blocks for that PEN, the length of the Custom Data field to be computed.

This means that readers will not be able to process arbitrary custom blocks unless they provide a plugin mechanism that allows, for an arbitrary PEN value, a plugin to be provided that understands the custom block formats for that PEN. That also means that if such a plugin is provided, it must be updated whenever the format of its PEN's custom block is extended to, for example, add a new subtype of custom block.

(And, yes this means that, given that Wireshark does not provide such a plugin mechanism, Wireshark, "out of the box", cannot process arbitrary custom blocks; it can only process custom blocks for which code in wiretap/pcapng.c includes support code.

And, yes, that needs to be fixed.)

[mcr]

Guy Harris ***@***.***> wrote: If a block supports options, you cannot have the length of the non-options part of the block contents be derived solely from the block total length, as that length includes the length of the options - you must have some other mechanism that allows the length of the non-options part of the block to be determined. Ick. Can we deprecate custom blocks with options, and create something new that doesn't suck?

[guyharris]

Ick.

That was my reaction when I realized this. I wish I'd realized it when it was first proposed.

Can we deprecate custom blocks with options, and create something new that
doesn't suck?

Or, at least, that has fewer problems.

If we insist that "Custom Blocks Done Right Blocks" pick a standard byte order for multi-byte integral and floating-point fields, and go with IEEE 754 for floating-point fields (VAX is dead, Data General is dead, 36-bit and 48-bit mainframes have other problems in a power-of-2-word-size world, and IBM mainframes now do IEEE 754), that should, I think, make it possible for code that knows nothing about the innards of a given Custom Blocks Done Right Block pass it through even if it's running on a machine with the opposite byte order from the machine that last wrote the file.

[mcr]

Guy Harris ***@***.***> wrote: If we insist that "Custom Blocks Done Right Blocks" pick a standard byte order for multi-byte integral and floating-point fields, and go Sounds good to me.