guyharris
commented
5 years ago Unfortunately, any file written by a program using the new block types would be unreadable by all versions of 1) programs using libpcap, 2) any of the programs shipped with Wireshark that read capture files, or 3) any other code reading pcapng files, until new versions of that software is released, and even then the software would have to be upgraded to the new version.
That would be an extremely disruptive change from the point of view of users.
It's not that painful to read an SHB.
If you're reading the first SHB in order to determine whether the file is a pcapng file or not, note that an SHB must be at least 12 bytes long. Try to read the first 12 bytes; if the file doesn't have 12 bytes, it's not a pcapng file. Otherwise, if the first 4 bytes are an SHB block type, and the third 4 bytes are a valid value of the byte-order magic number, it looks like an SHB; you now know the byte order, so you can convert the second 4 bytes to a block length. If it's < 16, it's invalid, so it's either not an SHB, hence it's not a pcapng file, or it's a bad SHB, in which case it's an error; if it's >= 16, it's a valid SHB, so read the rest of the block. Otherwise, it's not an SHB, so it's not a pcapng file.
For reading subsequent SHBs, you do the same, but treat "not an SHB" as an error. You have to treat SHBs specially in any case, given that a section has its own byte order and its own set of interfaces.
I might miss something here, but the parsing of an SHB is specifically hard due to the byte order being contained after the block length. So how about we introduce two new BlockTypes, such as LitteEndianSectionHeaderBlock (0x0a1b2c3d) and BigEndianSectionHeaderBlock (0x3d2c1b0a). Both Blocks would have the same design as the current SHB, but without the byte order magic.