On Feb 14, 2014, at 7:41 PM, Chris Kilgour <tec...@whiterocker.com> wrote:
> It seems some folks choose little-endian for multi-byte fields and others
> choose network/big-endian. It there a preference here? Is it acceptable to
> define these fields as having the same endianness as the pcap file header (or
> pcap-ng section header)?
Choosing a standard byte order means that libpcap and Wireshark's Wiretap
library don't have to, when reading a capture file, byte-swap fields in the
pseudo-header if it's being read on a host with a byte order different from the
host that wrote the file being read.
Using "byte order of the host that wrote the file" means that the code writing
the file doesn't have to put the header in a standard byte order.
We have examples of all three types of data in pseudo-headers, so there's no
obvious precedent for any of {big-endian, little-endian,
host-that-wrote-the-file-endian}.
If the pseudo-header is extensible and the code to byte-swap the files in
libpcap wouldn't be able to handle arbitrary extensions, a standard byte order
should be used. In other cases (for example, a fixed-format pseudo-header, or
a pseudo-header with TLVs where the T and L are host-endian but the V is in a
standard byte order, like LINKTYPE_BLUETOOTH_LINUX_MONITOR),
host-that-wrote-the-file-endian is acceptable.
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
