[pcap-ng-format] Proposal for new "custom" option codes

Hadriel Kaplan the.real.hadriel at gmail.com
Wed Jul 22 18:32:56 UTC 2015


On Wed, Jul 22, 2015 at 1:54 PM, Guy Harris <guy at alum.mit.edu> wrote:
>
> One problem with binary options, however, is that, if it contains values where byte order matters (integral or floating-point values larger than one byte), and a file written by a machine with one byte order is read, processed, and written by a machine with the opposite byte order (we ignore the PDP-11 here, which we can probably safely do :-)), unless the program writing it understands the binary option in question (either with built-in code or plugins), it can't write the option in question out and have it be properly interpreted by some other program, as the byte order of the data in the option will no longer match the byte order specified by the SHB of the section containing it.

Right, so for the draft's text one of the things I was going to
propose it say is something like:

"Implementers writing Custom Binary Options should be aware that a
PCAPNG file can be re-written by machines using a different endianness
than the original file, which means all the known fields of the PCAPNG
file will change endianness in the new file. Since the Custom Binary
Option payload might be an arbitrary sequence of unknown bytes to such
machines, they cannot convert internal multi-byte values into the
appropriate endianness.

For example, a little-endian machine can create a new PCAPNG file and
add some Custom Binary Options to some Block(s) in the file. This file
can then be sent to a big-endian host, which will convert it to
big-endian format if it re-writes the file. It will, however, leave
the Custom Binary Options payload alone (as little-endian format). If
this file then gets sent back to the little-endian machine, then when
that little-endian machine reads the file it will detect the format is
big-endian, and swap the endianness while it parses the file - but
that will cause the Custom Binary Option payload to be incorrect since
it was already in little-endian format.

Therefore, the Custom Binary Option should either encode all of their
fields in a consistent manner, such as always in big-endian or always
little-endian format, regardless of the host platform's endianness; or
the Custom Binary Option should encode some flag in its payload to
indicate which endianness the payload is written in."

-hadriel


More information about the pcap-ng-format mailing list